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Vegyen részt BIZTOSAN induló őszí/téli 
képzéseinken, és a tanfolyami díj 
-át felhasználhatja 2007-ben! 


Néhány képzés ízelítőül. Teljes akciós kínálatunkért figyelje internetoldalunkat! 


Windows XP üzemeltetés (2272) - november 13-17. 

Windows 2003 üzemeltetés (2273) - november 6-10. 

Windows 2003 hálózatüzemeltetés (2276/77) - november 6-10. 
Windows 2003 Active Directory (2279) - november 27-december 1. 
Visual Studio 2005 Windows fejlesztés haladó (2547) - november 16-17. k 







ITIL Foundation - november 27-30. ; 
SOL Server 2000/2005 alapok, lekérdezések (2071) - november 13-14. 
SOL Server 2000 programozás (2073) - november 20-24. 

Exchange Server 2003 üzemeltetés (2400) - november 27-december 1. 
BizTalk Servery2006Ialkalmazásfejlesztés (2933) - november 20-24. 
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Windows 2003 hálózat TETEEEZET ETVE € (2278)ildecember 4-8. 
Visual Studio 2005 osztott alkalmazásfejlesztési(2548) - december 6-8. 
SOL Server 2000 adminisztráció (2072) - decembet4-8. 
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Az akcióval és jelentkezéssel, valamint induló tanfolyamokkal kapcsolatos további 
információkért, kérjük, látogassa meg weboldalunkat (Akciók), vagy keresse munkatársainkat! 
Képzéseinkre szakképzési hozzájárulás illetve SA oktatási utalványok is felhasználhatók! 
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Még szerencse, hogy ez nem jelenthet 








kihívást a mai szoftverekkel. 
Olyan könnyű az egész. 


feladat általában egyszerűen hangzik: hatékonyabbá kell tenni a vállalat alkalmazot 
tainak mindennapi munkáját. De mire van szükség ahhoz, hogy ezt meg tudjuk való- 
sítani? Kiváló szakemberekre. 
Olyanokra, akik képesek megfelelni a gyakran egymásnak ellentmondó, folyton változó igé- 
nyeknek, és le tudják fordítani az üzleti igényeket az informatika nyelvére - és nemcsak el 
méletben, hanem a gyakorlatban is. Az elméleti, általános tudás megszerzése ma már szinte 
gyerekjáték. Elektronikus levelezésre van szükségünk? Telepítsünk egyet, a már jól bevált meg- 
oldások közül! Next-Next-Finish, és máris működik! Minek ehhez gyakorlat? 

Hihetetlenül sokan gondolkodnak így, és ebben persze szerepük van az egyre könnyebben ke- 
zelhető szoftvereknek is. Mégis, ha hiányzik a telepítés előtt a körültekintő tervezés, vagy nincs 
meg a gyakorlati tapasztalatunk az igazán alattomos hibák elhárításához, bármikor összedőlhet, 
amit építettünk. Annak pedig senki sem örül, ha nem megy a levelezés, vagy eltűnnek doku- 
mentumok, és nincs róluk mentés. Sőt. Kitör a pánik, és előbb-utóbb valódi szakembert hív- 
nak, aki már lehet, hogy későn érkezik. 

Kétségtelen, hogy szükség van a megfelelő alapozásra. Ismerni kell a bevált folyamatokat, 
módszereket, és tudnunk kell olyan biztos alapot adni informatikai rendszereinknek, ami min- 
den pillanatban stabil, akár egy betonfal, de szükség esetén rugalmas is tud lenni, mint a gumi. 


Még mindig egyszerűnek tűnik? 


NULL SEN Áááá 
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Clients 


Tanuljunk együtt! A PowerShell használata 

(Fóti Marcell) 

Aki látja a jövőt, az tudhatja, hogy a PowerShell mindent visz. Előbb-utóbb mindenkinek 
ugyanúgy meg kell tanulnia, mint annak idején a DOS-t - egyszerűen nincs nélküle élet 


6. oldal 


a Windows-világban 


Windows Server System Reference Architecture 

(lepenye Tamás) 

Egy informatikai vezető vagy rendszermérnök gyakran ütközhet olyan akadályba, amilyennel 
még sohasem találkozott korábban. Ilyenkor nagyon jó volna, ha azonnal használható 


ötleteket kaphatna az adott problémához 10. oldal 


Tervezz merészen! 

(lepenye Tamás) 

Sokan azt gondolják, hogy a szerverparticionálás a nagyvállalatok játékszere. Ez egyáltalán 
nem így van. A virtualizáció olyan lehetőségekhez juttathatja a kis- és közepes vállalatokat, 


amilyenekről eddig csak álmodni lehetett 13. oldal 


Van új a nap alatt 

(Gál Tamás) 

Szeptemberben jelent meg az ISA-kiszolgálók harmadik generációs képviselője, az ISA 
Server 2006. Megjósolható volt ugyan, hogy első ránézésre drasztikus változást nem fogunk 
tapasztalni az előző verzióhoz képest, de ha kicsit alaposabban megvizsgáljuk, akkor azért 


több fontos, hasznos és nagyléptékű újítást is felfedezhetünk 16. oldal 


Mentés és visszaállítás 

(Gömöri Zoltán) 

Bár ezen a téren a Windows Vista és a , Longhorn" Server jelentős újdonságokat fog 
felmutatni, érdemes megnézni, hogy milyen eszközök állnak már most rendelkezésünkre 


18. oldal 


adatmentési célokra a Windows Server 2003-ban 


Microsoft TechNet 
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Biztonság 


Biztonságos arcvonal 

(Kelemen László) 

A Microsoft 2006 júniusában 
bejelentett Forefront koncepciója 
olyan termékcsalád, amelyet 
kifejezetten az üzleti rendszerek 


22. oldal 


védelmére szánnak 





Infrastruktúra 


Messze vagyunk még? Messze. . . 
(Budai Péter) 

Hogyan lehet a szerverszoftverek 
skálázhatóságát alapul véve megoldást 
találni a kliensszoftverek 
teljesítményének javítására 25. oldal 
A parancsnoki fülkében ülve 

(Budai Péter) 

Mi az informatikus feladata egy meglévő 
rendszer üzemeltetésekor? Ismernie kell 

azt minden részletében. Az adott rendszer 
minden felmerülő és meglévő hibájáról 
tudnia kell. A hibákat a lehető 
leghamarabb ki kell javítania 
- System Center Operations 
Manager 2007 29. oldal 
A Windows Vista bevezetése 

(Moldova György) 

Bár sok hasznos újdonság érkezik 

a Vistában, azonban a bevezetésért 

felelős informatikusok csak egy dolgot 
kérdeznek: könnyebb lesz-e 

32. oldal 


ezt bevezetni 


OL HELSED Áá E áá 


WSUS 3.0 Beta 2 

(Gál Tamás) 

Megétkezett a Microsoft központi frissítés- 
kezelő és telepítő alkalmazásának következő 
változata, egyelőre csak tesztverzióban, 

de jó pár újdonsággal 36. oldal 
A PKI-infrastruktúra kiépítése 

(Urbanovits György — Kiss Mihály — Babócsy László) 

Az elvárás a következő volt: legalább 

5000 különféle, egymástól független, 
munkacsoportban vagy különböző 
tartományi tagként üzemelő 
munkaállomáson digitális aláírás 
megvalósítása elektronikus 

levélben, több ezer felhasználó 


38. oldal 


számára 


Alkalmazásplatform 


SOL Server 2005 Reporting Services 
(Kovács Zoltán) 

Ha valaki saját alkalmazásához 
jelentéskészítő és megjelenítő eszközt 
szeretne illeszteni, vagy jelentésplatformot 
kell választania, akkor jól teszi, 

ha megismerkedik az SOL Server 2005 
Reporting Services által nyújtott 


alkalmazásintegrációs 


lehetőségekkel 41. oldal 
[TT EE Ez] 
Szoftvergyárak 

(Nagy Levente) 


A szoftvergyártás Ford I-Modellje 

a sablon. Egyszerű, általános céloknak 
megfelelő példányokat könnyen 
generálhatunk, ilyenek a Visual Studio 
sablonjai, de még inkább az egyes 
Starter Kitek, amelyek már önmagukban 
is kész alkalmazások, vagy elővehetünk 
olyan kész építőkockákat, blokkokat is, 
mint amilyenek például 


a Patterns 6 Practices mintái 45. oldal 
ENNYI] 


ici 


A Sharepoint keresőszolgáltatása 

(Pölös Máté) 

A Sharepointcsaládban két kereső 

is van, de jó tudni a különbséget 

a Windows Sharepoint Services v2 (WSS) 

és a Sharepoint Portal Server 2003 

(SPS) lehetőségei között 47. oldal 





Közösség 


Nem szabad lemaradni 

(Budai Péter) 

A visszajelzésektől a terveken, 
a ITechNetmodulokon át 

a legkiemelkedőbb 
szakemberekig és 


a Windows Vistáig 50. oldal 
HESS EZTZET]] 
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Ime a parancssor, ami forradalmasítja a rendszerfelügyeletet. 


ki látja a jövőt, az tudhatja, hogy a PowerShell mindent visz. Előbb-utóbb mindenki- 
nek ugyanúgy meg kell tanulnia, mint annak idején a DOS-t - egyszerűen nincs nél 
küle élet a Windows-világban. Korábbi számunkban már adtunk egy alapos áttekintést 
arról, hogy mire is képes az új shell, azonban a következőkben tényleg az alapoktól kezdve, 
gyakorlatilag nulláról fogunk hozzá, hogy megmutassuk, hogyan érdemes elsajátítani az új pa- 


rancssor használatát. 


2 Windows PowerShell 
Windows Power$hell 
Copyright (CC) 2886 Microsoft Corporation. All rights reserved. 


PS C:MDocuments and SettingsMVÁdministrator? dir 
Directory: Microsoft.PowerShell.CoreMFileSyustem::C€C:XDocuments and SettingsXÁdministrat 


LastWriteTime Length Name 


jn TES Tá moj vi] 
Favorites 
My Documents 
Start Menu 
UserData 

8 Sti Trace.1log 


PS €C:MDocuments and SettingsXMÁdministrator? dir /s 


PS C:Documents and Settings"Administrator? , 


1. kép. A hagyományos, DOS-os belső parancsok nem pont ugyanúgy működnek 


Az első olyan kiszolgálótermék, amelyik nem fog , vacakolni" a hagyományos VBScriptes, 
COM-os rendszerfelügyelettel és automatizálással, az Exchange Server következő változata 
lesz. Utána szép lassan az összes kiszolgálóterméknél is be fogják vezetni a .Net keretrendszer- 
re épülő automatizálási lehetőséget, így például az új MOM-nál is, ami már a System Center 
Operations Manager 2007 nevet kapja megjelenésekor. 

Nulláról úgy kell indulni, hogy telepítjük a jószágot. A Microsofttól letölthető 1,6 mega- 
bájtos csomag néhány másodperc alatt telepíthető a .Net Framework 2.0-val természetesen 
már régen felvértezett operációs rendszerre. Ahol nincs fent a legújabb Framework, ott a tele- 
pítő megáll, és reklamál. A hiányosság pótlása után pillanatok alatt elérhető az új parancssor. 
Az első parancs, amit ki , kell" adnunk, természetesen a DIR lesz. És minő meglepetés, egy 


könyvtárlistát kapunk eredményül. Eddig rendben, a nehezén túl vagyunk, ez is csak egy pa- 


[4 





rancssor. Próbálkozzunk most valami nehe- 
zebbel, mondjuk a DIR /S paranccsal! Hát ez 
nem jött össze (Il. kép). 

Szép piros hibaüzenet tájékoztat arról, 
hogy a C:S5 könyvtár nem létezik. Ebben tel 
jesen igaza van, de ki akart oda menni? Mi 


történik itt? 


DOS-os fejjel... 


Próbálkozzunk a jól bevált , fejjel a falnak" 
módszerrel (a dokumentációt pedig tartsuk 
távol magunktól!), és kérjünk egy helpet a 
DIR-parancsról! 


HELP DIR 


Talán meglepő, de működik a help pa- 
rancs. A válaszból kitűnik, hogy a DIR be- 
csületes neve GetChildltem, és az is kiderül, 
hogy hogyan kell leküldeni az alkönyvtárak: 
ba: recurse, vagy egyszerűen: r kapcsolóval. 
Joggal kérdezhetik, hogy miért változott meg 
az égvilágon minden, ha egyszer ugyanazt a 
feladatot hajtja végre a GetChildItem, mint 
a DIR parancs. 

Mert nem ugyanazt végzi el, nem ugyan- 
úgy, és nem ugyanazzal az eredménnyel! A 
GetChildIltem elég sokféle típusú adathal 
mazból képes listát generálni, többek között 
könyvtárakról is. Továbbá például regisztrá- 
ciós adatbázisból, tanúsítványtárból is... 


A Help parancs úgy mutatkozik be ne- 


Microsoft TechNet 





künk, hogy ő bizony a GetHelp, ezért mos- 
tantól használjuk így. A következő feladat a 
könyvtárváltás (CD) parancs lesz. Kérdezzük 


le, ő ki fia-borja? 


Get-Help CD 


, Én vagyok a SetLocation! (Valójában a 
CD csupán egy alias, egy becenév a Set 
Locationre, lásd: getaalias.) Ha csak úgy egy- 


patt tatás) k- 


PS C:MWIINDOWS? dir : get-member -membertype property 


TyupeName: Syustem.I0.Directorulnfo 
MemberTyupe Definition 


Attributes 
CreationT ime 
CreationTimeltc Property 
Exists Property 
sion Property 
FullName Property 
LastAccessTime Property 
LastAfccessTimeUltc Property 
LastWriteTime Property 
LastWriteTimeltc Property 
att Property 
és Zip Én Property 
ÉTER Property 


Property 
Property 


TypeName: System.IO0.Filelnfo 
MemberType Definition 


Property 
Property 
Property 
Property 
Property 
Property 
Property 
Property 
IsReadOnly Property 
LastAccessTime Property 
LastAccessTimeltc Property 
LastWriteTime Property 
LastWriteTimeUtc Property 

Property 

Property 


DirectoryName 
Exists 


PS C:NWINDOWSD 
a 


lálnunk, de itt még nem tartunk. Egyelőre 
állapítsuk meg, hogy - ellentétben a DOS-os 
külső és belső parancsok elnevezésével és szin- 
taxisával - egy konzisztens névtérben találjuk 
a parancsokat, amelyek hivatalos elnevezése: 
Commandlet, parancsocska. Amíg a koráb- 
bi shellekben egy parancsot pont úgy hív- 
nak, ahogy azt készítője megálmodta (például 
NetSh, Driver(2uery stb.), és a nevek között 
semmilyen rendet nem lehet felfedezni, most 


mindegyikük neve egy kéttagú kifejezés, ahol 


:zJDl 2] 
Al 


System.I10.FileAttributes Attributes fget;set;?2 
System.DateTime CreationTime (fget;set;2 
System.DateTime CreationTimeltc (get;set;?2 
System.Boolean Exists (fget;?2 

System.String Extension (get;?2 

Syustem.String FullName (get;? 
System.DateTime LastAccessTime fget;set;? 
Syustem.DateTime LastfAccessTimeltc (get;set;2? 
Syustem.DateTime LastWriteTime (f(get;set;? 
System.DateTime LastWriteTimeltc fget;set;2 
System.String Name (get;? 
System.IO.Directorylnfo Parent (get;?2 
System.IO.Directorylnfo Root (fget;2 


.[10.FileAttributes Áttributes (get;set;2? 
System.DateTime CreationTime (fget;set;? 
System.DateTime CreationTimeltc fget;set;2 
System.IO0.Directoryulnfo Directory (get;? 
System.String DirectoryName (fget;? 
System.Boolean Exists (get;2 
System.String Extension (get;2? 

System.String FullName fget;? 

System.Boolean IsReadünly (fget;set;52 
System.DateTime LastfccessTime (fget;set;? 
System.DateTime LastAccessTimelte (fget;set;?2 
System.DateTime LastWriteTime (gets;set;2?) 
System.DateTime LastWriteTimeltc (get;set;? 
System.Int64 Length fget;2 

System.String Name (get;2) 





2. kép. A Get-Childltem a fenti adatokat kezeli a fájlrendszer objektumain 


magamban használsz, már sokkal többet 
tudok smint vatjó töres "CD parancs," hisz 
át tudsz állni velem a registryre, a tanúsít 
ványtárra, hogy ott listázgass testvéremmel, 
a GetChildltemmel. Sőt! Van memóriám! 
Bármikor elmentheted velem, 
hogy hol jársz éppen a Push- DIR TXT S 
Location  testvérparanccsal, 


a registryből 
DIR "EXE 


ahová tetszőleges pillanat 


ban visszaugrom, ha kiadod a 
Pop-Location parancsot!" 


Nézzünk néhány példát! 


Amit az eddigiekben láttunk, 
vs ; ; pontra 
csupán a jéghegy csúcsa, hisz 

a mélyben valahol valami dot 


netes döbbenetet kellene ta- hajtóra 


A HKLM/Software ág kilistázása 


Átállás a A: meghajtóra 


at 


Jelenlegi , állás 


Átállás a HKEY. CURRENT. USER 
ágra a registryben 


elmentése 


Visszaugrás egy korábbi mentési 


Atállás a tanúsítványtár , meg- 


elöl áll a művelet rövid neve (például Get, Set, 

Format, Start, Stop stb.), majd kötőjellel elvá- 

lasztva egy objektumnév (például Service). 
Ezen túlmenően a parancsok szintaxisa 


és kapcsolói is konzisztensek, mert maga a 


Get-Childltem . —Include "txt -Recurse 
Get-Childltem registry::HKLM/Software 


Get-Childltem " -I "exe 
Set-Location 0: 


Push-Location 


Set-Location HKCU: 
Pop-Location 


Set-Location Cert: 


PowerShell felelős a paraméterek kezeléséért, 
nem pedig a parancsocska. Ennek az a prak- 
tikus oka, hogy a parancsocskák a háttérben 
nem stringekkel, hanem .Net objektumok 
kal manipulálnak, ezekkel végzik a művele- 
teket, amelynek gyakran az a végük ugyan, 
hogy kiírjuk a képrenyőre az eredményeket 


- de ez nem feltétlenül van így. 


Számtalan shellt ismerünk, ahol a futtatott 
parancsokat egymáshoz lehet csatolni a pipe 
( ] ) karakterrel, ám a korábbi parancskör- 
nyezetek az egyes parancsok között csak és 
kizárólag stringeket tudtak közvetíteni. Ha 
az inputoutput valójában dátum - akkor is 
string. Emiatt aztán minden parancs kény- 
telen az input stringből kimazsolázni és saját 
belső adattípusára konvertálni azt az adatot, 
amire szüksége van. Ez sok esetben annyira 
bonyolult lenne, hogy hozzá sem kezdünk. 

Próbálte már valaki egy DIRlistából dá- 
tumokat vagy Read Only flageket kivonatol 
ni? Esetleg egy IPConfig outputból kiemelni 
a Default Gateway címét? Hogy futna ez a 
kód egy német Windowson, vagy uram bo- 
csá egy kínain? Elég lehetetlen feladat, a 
100 százalékos pontosság eléréséhez mester- 
séges intelligenciára lenne szükség. Mivel ez 
utóbbit még nem találták fel, marad a kézi 
hajtány-rmegoldás, illetve egy olyan kapcsoló 
a parancsba, ami feldolgozási hiba esetén is 


engedi továbbfutni. Nem elegáns! 


Mi: lenne, ha minden adat megmaradna a sa- 
ját natív formátumában, és így menne át a 
csöveken? Közelítünk a lényeghez - ugyanis a 
PowerShell pontosan ezt teszi! Valahányszor 
lekérdezünk egy listát, valójában a mögöttes 
.Netobjektumok kupacát (collection) kap- 
juk vissza, amit akár ki is boríthatunk a kép- 
ernyőre (ilyenkor persze stringgé alakul), de 
tovább is passzolhatjuk a pipe karakterrel, 
anélkül, hogy információt veszítenénk! 

A motorháztető alá be is lehet kukkanta- 
ni, ugyanis a speciális getmember Cmdlet 
arra való, hogy kilistázza a , belepájpolt" .Net 
objektumok tulajdonságait (property) és me- 
tódusait. Példaképpen (2. kép) íme a Get 
ChildItem-kimenet GetMemberbe csövezé- 
sének eredménye (csak a propertyk). 

Jól látható, hogy minden adat megőrzi a tí- 


pusát, tehát például a FullName String, de a 











LastAccessTime Datelime típusú, míg az al- 
só listában szereplő IsReadOnly egy Boolean 
(logikai) típust képviselő adat. 


Bizonyítsuk be, hogy minden adat megőrzi a 
típusát! Ha beírjuk a parancssorba, hogy 1, 
ezzel nem egy szintaktikai hibát adtunk meg, 
hanem egy int típusú konstansot. Írjuk be 
azt, hogy I-1, és a válasz 2 lesz - a Shell te- 
hát elvégezte az alapműveletet! Akár úgy is 
tekinthetjük, hogy nem egy parancssorban, 
hanem egy programozási környezetben, sőt, 
méginkább egy lépésenkénti futásra kénysze- 
rített programban vagyunk. Állunk a feldok 
gozás közepén, és látjuk, sőt, módosíthatjuk 
a futás feltételeit - mint egy debuggerben. 

Mi több, változókat is létrehozhatunk, 
adatokat tölthetünk bele, és amíg a Shell 
fut, ezek meg is maradnak. Mit tehetünk 
egy PowerShell változóba? Bármit! Akár egy 
DIR teljes eredményét! Lássunk erre egy pél 
dát (3. kép)! 

Az első sor nem ad vissza eredményt a 
képernyőre, mivel azt ,lenyeli" a $akarmi 
nevű változó. A második sor borítja elénk 
a $akarmi tartalmát, ami egy komplett, ob- 
jektumorientált könyvtártartalom-kollekció! 
Később látni fogjuk, hogy van egy speciális 
változó, a $. , ami mindig az aktuális objektu- 
MOL tartal razza 


Most térjünk vissza a csőbe... 


Gyakran lehet szükség arra, hogy csak bi 
zonyos objektumokat dolgoztassunk fel a 
csőben, vagyis meg kellene szűrni az átju- 


tó objektumokat valamilyen feltétel szerint. 





PS C:N2 Sakarmi-dir 
PS C:XN2 S$akarmi 


2. Windows PowerShell 


Bizonyos parancsok eleve tudnak szűrni né- 
hány mezőre (például a DIR épp ilyen), azon- 
ban még ennél is szükség lehet egy általános 
szűrőre, amelyik tetszőleges mezőérték alap- 
ján képes szűrni. Erre találták ki a Where- 
Object Cmdletet, amelyik egy megadott szű- 
rőfüggvény alapján rostálja át az objektumo- 
kat. Az alábbi példa az Event Logból csak és 
kizárólag az Error típusú bejegyzéseket listáz- 
za ki, vagy adja tovább a csőben, ha van még 


feldolgozóegység: 


get-eventlog system ] where-object -filterscript 
1($. entrytype -eg , error") 


Egy kis segítség a fenti furcsa képlethez: $- 
az aktuális objektum a csőben, -eg nem más, 
mint , egyenlőségjel". Ami most a csőből ki- 
potyog, egyenesen a képernyőre kerül. Írjuk 
fájlba! Ehhez mindössze a végére kell csövez- 


ni az outfile parancsot: 


get-eventlog system ] where-object -filterscript 
A -entrytype -eg , error") ] out-file cXuaa.txt 


Ez a szűrés után fennmaradt összes Error 
típusú objektum valamennyi mezőjét gon- 
dolkodás nélkül kiírja a fájlba. Lehetőség 
van azonban az adatok kimazsolázására is. A 
csőben érkező objektumkupac ugyanis nem 
más, mint egy foreach-csel bejárható gyűjte- 


mény, magyarul collection! 


Az objektumkupacok egyenkénti feldolgozá- 


sát - mint minden rendes nyelvben - itt is 


Directory: Microsoft.PowerShell.CoreMFileSystem::CzN 


LastWrpriteTime 





Length Name 


Documents and Settings 
Inetpub 

Program Files 

swsetup 

WINDOWS 

jdlugsi tás 

1 ETT 


aaa.txt 

A AUTOESEC. BAT 
bbb.txt 
CONFIG.SYS 


3. kép. A Sakarmi változóba betöltjük a DIR kimenetét, majd ki is listázzuk 


a foreach konstrukció teszi lehetővé. (Ennek 
pontos neve: ForEachObject, de működik a 
foreach alias is.) 

Alkossunk egy egyszerű objektumkupacot 
a feldolgozás megértésének egyszerűsítésére! 
A legegyszerűbb collection egy statikus felso- 


rolás, mondjuk például: 


234 


Ha valaki ezt a négy számot így begépeli a 
PowerShellbe, érdekes módon nem , syntax 


error"-t kap válaszul, hanem ezt: 
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3. 4 





4. kép. Egyszerű objektumkupac 


Itt egy négyelemű collectionnal van dol 
Súnk "ami ost hústán kitölyiksasstdontsa 
(képernyő). Azonban a kupac elemeit fel is 
tudjuk dolgozni! Például számoltassuk ki a 
parancssorral a csőben kapott sugarú kö- 
rök területét, vagyis szorozzuk meg mindet 
23, 14-gyel (5. kép.)! 

Most már nyugodtan nekieshetünk az 
Error típusú Event Log-bejegyzések ciklikus 
feldolgozásának. Legyen az a feladat, hogy 
csupán a hibaüzeneteket írjuk ki, a többi 


adat nem kell! 


get-eventlog system ] where-object -filterscript 
AS. -entrytype -eg , error") ] foreach -process 
fadd-content aaa.txt $. .Messagek 


Ugye, milyen egyszerű? Hát nem. Fél óráig 
kellett bütykölni, amíg ez így összejött, még- 
pedig azért, mert korábban egyszer belenavi 
gáltuk a tanúsítványtárba, és ott próbáltuk 
meg lefuttatni, amire a következő érdekfeszí- 
tő, pirospozsgás, de teljesen semmitmondó 


hibaüzenetet kaptuk: 


Cannot use interface. The IContentCmdletProvider interface 
is not implemented. 
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Nesze neked, rendszergazda! Lesz itt még 


mit tanulni! 


Konklúzió és további lehetőségek 

A Microsoft célja alapvetően az, hogy min- 
den parancs vagy lista, ami az MMC konzo- 
lon vagy egy webes adminfelületről elérhető, 
illetve amit az adott szerveralkalmazás kiajánl 
magából automatizációhoz vagy saját felügye- 
letéhez, az Windows PowerShell scriptletek 
vagy providerek formájában is rendelkezésre 
álljon. Így a rendszergazda eldöntheti, hogy a 
grafikus vagy a parancssoros interfészt hasz- 
nálja feladatainak elvégzéséhez. A grafikus 
felület nyilván sokak számára egyszerűbb, 
azonban a parancssor használatával messze 
több lehetőségünk adódik; például ugyan- 
azokkal az eszközökkel barangolhatunk a 
registry, a fájlrendszer, a tanúsítványtár vagy 


éppen az Exchange-mailboxok között, és egy 


az New Mailbox 


EL Intraductian ( Completian 
JE User Tupe 
EL Hailbox Information 
IE Hailhox 5 ettinae 
ET Hew Mallbox 


EE Campletion 


! Elápsed time: ÜL:ÜÜ: 1 Ü 


Éz Frank. 











nénk matatni a levelezőszerverünkön, meg- 
tehetjük a Windows PowerShell alapokra 
épülő Exchange Management Shellel is. Az 
Exchange 2007 - nagyon hasonlóan az SOL 






ee PowerShell 
Er IREK JE 
6.28 
12.56 


5. kép. Excel tábla helyett használjon ön is PowerShellt! 


Server 2005-höz - képes már arra is, hogy ha 
a grafikus felületen módosítunk valamit, azt 
scriptként is visszaadja nekünk. Mégpedig 
egy olyan PowerShellscript képében, amit 


The vazard completed succesztully. Ta close this wizard click. Fimizh. 


summarnt ] items. ] succeeded, Ü failed. 


A completed Áá 


MHanacdement Shell command completed: 

Hew-Mallbox -Harne: Frank Lee -állaz: trank" -ÖraganizationalLÍnit: contoza comilzers" 
Database: LN-Mallbox Database CN-First Storadge 

Group CM -lntormattoná tore CH-w I HZOOSMS ÉN-Servers LH-Exchange 


Administrative Group [FTUIBÜHF2zSSFOLT IJEN -ádmirtetrative Groups CM-Firet 


Organization LN-Microzolt 


Exchange CN-Services CLN-Conrfiguration UC-contoza DC-com 

LIWserFrincipalNl ame: frankcöcorntoza com -S ami ccountH ame: rank -FirstN ame: Frank. 
rittals:" -Last Name: Lee -Faszsword; Sustem Securitu, Securestring 
-ResetlFazszwordunNestLagort false 


Elapszed T irne: ÜNÜN: 1 Ű 


select CtrkC ta copy the contents ol this page. 


Help I 


£ Back IL Fnih ] tamncel j 


6. kép. Azonnal használható PowerShell-script az Exchange Server 2007 varázslójában 


nagyon korrektül összerakott, típusos, .Net 
alapú scriptnyelvvel dolgozhatunk az ott ta- 
lált adatokkal. 

Az Exchange Server 2007-ben szinte min- 
den funkció elérhető lesz az új MMC kon- 
zoljáról, azonban ha automatizálni szeret 


nénk működését, vagy parancssorból szeret 


tata EN NAg Ét ád 


azonnal túdünk használmi az új baTramcssor 
Dan vagy automatizáláshoz: 

Az pedig, hogy a PowerShell szinte telje- 
sen .Net alapú, még egy érdekességet mutat: 
a szerverszoftverek korábban szinte kizárólag 
programozóknak szóló APLjai és objektum- 


könyvtárai végre elérhetők lesznek egysze- 


ETTE ECET TE 


TETT SO 7 
NélsszJIllees asni 


rűbb formában a rendszergazdák számára 
is, a szeverszoftverek testreszabásához és au- 
tomatizációjához kevesebb alkalommal lesz 


szükség fejlesztő beavatkozására. Ezzel egy 









időben pedig a rendszergazdák is közelebb 


kerülnek a .Netes programozáshoz. 

A cikk megírásakor jelent meg a Windows 
PowerShell RC2-es változata jó néhány új- 
donsággal (például van benne közvetlen 
ADSLtámogatás is Active Directory elérésé- 
hez és WMI provider!). Elképzelhető, hogy 
a Magazin megjelenésekor (várhatóan az 
Exchange 2007 kódjának elkészültével egy 
időben) már elérhető lesz a weben az új pa- 


rancssor végleges telepítője. 


PowerShell Analyzer (bela) [1.0.1.1] 

File Edit Search  Runspace Code Completion — Outlning — Tools Help Community 
[RPO-xBIJODGA3]4 AaRADgAl0 z 
runspace! 

Console Output ! XML! [ Results Feninrer !  Provider Explorer! HTML ! Chart 


ni 
14) 
MT 
ui 


Heb Man 





index dass contents EE "e 
0 Svstem.Int32] 1 
TT tten] 





SyetemObjsetü[ 2 teme] 
index class contents 
System.Int32] 3 


9 System. Collections.Has.. (5 items 








PSDoc1.pst" gridtest.ps1 l 


9-71,2,13.RB( this -1;that - 3:mine - 4;subhash-Rf(a-[datetime1: : Now) ;deet 
10 
12] 

ln9 Colli Chi I 


pl 


Egy másik tool, a PowerShell Analyzer 


Ugyancsak az elmúlt napokban lett el 
érhető a http://powershell.com/ oldalon a 
Scriptinternals PowerShell scriptszerkesztő 
és debuggoló fejlesztőeszköze, ami teljesen in- 
gyenesen letölthető. 

Érzésre valahol félúton van a Turbo Pascal 
és a Visual Studio között, a design pedig az 
Office 2007-et idézi - de nagyon hasznos tud 
lenni komplexebb scriptek írásához. 

Fóti Marcell 
(marcellfcconetacademia.net) MCSE, MCT, MZ/X since 1995 
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Hz Xx 
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VVINDOWS SERVER 


SYSTEM REFERENCE 


AÁRCHITECTURE 





Egy informatikai vezető vagy rendszermérnök gyakran ütközhet 


olyan akadályba, amilyennel még sohasem találkozott korábban. 


Ilyenkor kellemes volna, ha már azonnal használható ötleteket 


kaphatna az adott problémához. 
A WSSRA ezért jött létre. Pontosabban: ezért is. . . 





égóta létezik, mégis alig kapott visszhangot, Magyarországon pedig 
egyáltalán nem lehetett látni-olvasni olyan publikációt, amely ezt a 
hatalmas és sok tekintetben példaértékű dokumentumhalmazt be- isdkáküt EE 


. A F 5 4 . ; (assigned to Network Adapter) 
mutatta volna. Pedig a problémák, amelyek miatt megszületett, teljesen ál EZ EMETERAK ETETETT e 


el ATS A ee TÁ Elfo ATM LTE AE KET el OT ATAA ÉSZÉGV TES NN ERRE STT 


Hogyan cseréljük le az informatikai infrastruktúra tervezésének hagyo- 
mányos látásmódját" Honnan kaphatunk kipróbált ötleteket egy adott 
problémához? 

Hogyan készítsünk üzemeltetési kézikönyvet egy szolgáltatáshoz? Milyen 


napi/ heti/ havi feladatok tartoznak egy szoftver üzemeltetéséhez? 


Képzeletbeli infrastruktúra 


A Microsoft partnereivel együtt elkészítette, majd dokumentálta egy kép- is 





zeletbeli vállalat teljes IIrinfrastruktúráját. Mindez több célt is szolgált. 





Bizonyítani szerették volna a Windows együttműködési képességét, skáláz- 


hm Network 5egme nt(frontend) a [e 






eENNGEASALENENA ASSE Ef A a nnenasea áttette ne enne ntta [dos e dossazsaszaszaszászázetánászztnanánét 


s, Server A ] instances, only one may be deployed. 


NIC 2 port 1(22)1.7 


Mm NEIWOIK 500 ment (backend) 8 3 [/ 










Virtual IP $1 
(for server farm) 






DIP $1 
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Note: Diagram depicts two server node 
configuration for simplicity, can scale to 
several nodes. Though Network Load 
Balancing of both the frontend and 
backend interfaces are shown in many 


s. 
"s 
a 






ve . 
decz ai ő 4 era, ésaz 
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Virtual IP (VIP) 42 
(for server farm) 






DIP 42) 








hatóságát, megbízhatóságát, komplex feladatokra való alkalmasságát. Ezen — Terhelésmegoszlás custerekkel a Security Architecture Blveprintben 


túl a cég egy , élő", működő, letesztelt példán keresztül igyekezett tapaszta- 
latokat átadni vevők/felhasználók számára. A WSSRA nem csupán a Microsofttermékekre 
igaz, habár elsősorban a Windows Server és a Microsoft szerveralkalmazások felhasználható- 
ságát hivatott bemutatni. A leírás többek között hálózati elemeket (Cisco), tárolórendszereket 
(EMC, HP), szerverhardvert is felvonultat (alkalmaz, méretez, üzembe állít stb.). A cél egy tel- 
jes és működőképes rendszer létrehozása volt. 

A WSSRA nem előzmények nélküli. Az első verziót a Windows 2000-hez készítették el, an- 
nak még , Microsoft System Architecture" volt a címe, és két részből állt: egy , Enterprise Data 
Center (EDO)" és egy , Internet Data Center (IDC)" fejezetből. Később úgy döntöttek, hogy 


Ld 


minden egyes Windows-verzióhoz elkészíte- 
nek egy referencia architektúrát, így jelent 
meg a mostani WSSRA 2.0-s verziószámmal. 
A jelenlegi megoldás még az eredeti Windows 
Server 2003, és nem a legfrissebb R2 változat 
alapján készült, az azomban bIZONYOS "NOgyi a 
Windowssszerver következő nagy verzióváltá- 


sával együtt a dokumentációs csomag is meg- 


Microsoft TechNet 
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újul majd. A megelőző verziót persze felhasz- 
nálták, de az EDC, IDC a 2.0-s változat szem- 
szögéből már csak egy modell, a teljes IL-inf 
rastruktúra része. Az új verzióban a modellek 
száma kibővült, olyan szituációkat is kidol 
goztak, mint a Department, a Branch Office, 
a Satellite Branch Office és az Extranet. A 
WSSRA egyik legnagyszerűbb tulajdonsága, 


zik a leírás, milyen egyedi dokumentumokat 
tartalmaz a WSSRA, azoknak mi a szerepük 
és hasznuk. Végül a , Lab Implementation of 
Windows Reference Architecture" (68 oldal) 
azt a tesztkörnyezetet írja le, amelyen felépült 
a WSSRA, továbbá olyan elnevezési és jelö- 
lési standardokat ismertet, amelyek alapján 


például a nevek és ábrák értelmezhetővé vál 

















hogy a szolgáltatás oldaláról közelíti meg a 
teljes problémát, olyannyira, hogy már ma- 
guknak a dokumentumrendszereknek a fel 


építése is a szolgáltatásokat követi. 


A WSSRA szerkezete 


A teljes WSSRA-anyag összecsomagolva 41 
megabájtnyi, kibontva 104 állomány és 74 
megabájt, tehát meglehetősen méretes va- 
lami. A tömörítés eltávolítása után három 
fő könyvtárat kapunk, ezek rendre Over 
view Documents (Általános ismertetők), 
Reference Blueprints (Elméleti tervezési is- 
meretek), Implementation Guides (Imple- 
mentációs útmutatók). 

A legkisebb, mindössze három Word-állo- 
mányt tartalmazó fejezet az első rész. A cso- 
porton belül a legelső dokumentum címe 
, Introduction to Windows Server System 
Reference Architecture" (27 oldal]: úgy értek 
mezi az egész anyagot, hogy leírja a problémá- 
kat, amelyekkel az foglalkozik, a módszere- 
ket, amelyekkel a problémákhoz nyúl, és tisz- 
tázza, hogy az olvasók (munkakörük alapján) 
mit nyerhetnek a betekintéssel. 

A , Getting Started with Windows Server 
System Reference Architecture" (26 oldal) azt 
rögzíti, milyen vállalatmodellekkel foglalko- 


tata EN NAg Ét ád 


nak. Ha valaki szeretne korrekt névkonven- 
ciót bevezetni, ebben a fejezetben találja meg 
az egyik legjobb példát. 

A WSSRA-dokumentumok második nagy 
csoportja a , Reference Blueprints". Sokáig 
kellett keresni, mit fed a Blueprint kifejezés: 
a másolaton túl , terv -et, , részletes terv "-et 
is jelent. A tartalom alapján a Blueprints 
olyan elméleti háttérinformációkat tartal 
maz, amelyek a későbbi tervezési és üzemel 
tetési útmutatók megértésében segítenek. Ha 
egyetlen mondatot sem jegyzünk meg ab- 
ból, amit a WSSRA megoldáshalmaza kínál, 
a Blueprintnek nevezett dokumentumokat 
akkor is érdemes elolvasni, mert ezek lénye- 
gében erősen a lényegre törő tankönyvek. 
Alapismeretek birtokában a Blueprintek ké- 
pesek a fejekben lévő ismereteket rendszerez- 
ni, kontextusba helyezni. 

Ha valaki végigolvassa őket (80-90 ol 
dal egy-egy állomány), akkor úgy érzi, hogy 
az adott témát (például Storage, Network, 
Active Directory stb.) minden aspektusában 
átlátja, a lehetséges problémákat ismeri, és 
bizonyos, hogy a saját rendszerére vonatko- 
zóan ötletei lesznek a jobbításra. 

A Blueprintek két csoportba sorolhatók. 


Az első csoport az , Architecture Blueprints", 


TETT SO 7 
eg mene 
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amely őt fő területtel foglalkozik általános- 

ságban: Application, Management, Network, 

SEGUTEN  OFOTaDE: 

A második csoport a , Service Blueprints", 
egy-egy adott szolgáltatás tervezési kérdéseit 
(de nem a konkrét tervezését!) tárgyalja. 
A Service Blueprintek egyébként nem is a 
, Reference Blueprints" mappában találha- 
tók, hanem az egyes szolgáltatásokhoz he- 
lyezték el őket. Logikailag mindkét helyre 
illenek, ezért a furcsa vonal a fenti ábrán 
a , Reference Blueprints" ágból a Service 
Bluprintekbe. 

A harmadik nagy dokumentumhalmaz az 
, [Implementation Guides", magyarul megva- 
lósítási útmutatók, amelyek minden egyes 
szolgáltatáshoz öt dokumentumot tartalmaz- 
nak. Ezek sorra: 

a Introduction (Bevezetés). Alapkérdések 
tárgyalása, miért van szükség egyáltalán a 
szolgáltatásra stb. 

n Service Blueprints (A szolgáltatás elméle- 
ti háttere). 

Guides 


tó). Ez már a konkrét (valójában a fiktív 


a Planning (ITervezési útmuta- 
Contoso nevű) vállalatnál a szolgáltatás 
felépítésének konkrét kérdéseit, dönté- 
si pontjait ismerteti minden egyes mo- 
dell esetén (EDC, IDC Brach Office stb.) 
Miután az adott szituációban az adott meg- 
oldást kiválasztották, megválaszolják azt a 
kérdést is, hogy miért így döntöttek. 

z Build Guides 


Pontosan, lépésről lépésre megvalósítják a 


(Telepítési útmutató). 
kiválasztott megoldást. Ha tehát valakinek 
olyan problémája van, hogyan kell valamit 
felépíteni, telepíteni, konfigurálni, jó esély- 
lyel megtalálhatja azt a konkrét szolgálta- 
tás Build GuideJjában. 

a Operations Guides (Üzemeltetési útmu- 
tató). A megvalósított megoldás üzemel 
tetési feladatainak rögzítése, valamint az 


eljárások definiálása. 


Nagy méretek 

sok-sok apró tanulsággal 

A WSSRA egy nagy multinacionális vállala- 
tot képzel el, több tízezer felhasználóval, sok 
száz szerverrel. Jogosan kérdezheti az olvasó, 
vajon neki, akinek csak 20-50-100-500 fel 
használója vain, vajon ún haszha Ilyen óriási 
méretű rendszer dokumentációján átrágnia 
magát? Miért jó a WSSRA a középvállalatok 


informatikusainak és döntéshozóinak, ami 


A 
a 
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kor náluk nagyságrendekkel kisebb rendsze- 
rekről van szó, kvázi ,ez nem róluk szól". 
Meggyőződésünk, hogy ez nem így van. 
Még ha a konkrét implementációt nem is 
lehet egy az egyben megvalósítani, az [[ 


infrastruktúra logikai felépítése lényegében 


egy minden szeletében precíz, teljes rendszert 
építhet fel, dokumentálhat és üzemeltethet. 
Nem tudjuk, hogyan nézzen ki egy rendszer- 
dokumentáció? - Koppintsuk le az itt látható 


struktúrát. Nem tudjuk, mi szerepeljen az 


üzemeltetési kézikönyvben? - Nyissuk ki a 





Service Monitoring 


2 d ká 


System/App Security . Performance  Archive 


Events § Alerts — Events 
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Security/System/ 
Performance Events 
8. Alerts 


Centralized 





Patch Deployment 


Operational Administration Storage 
Reporting Management 


System, Network, 
Directory, Security, 


Backup, Patch, 
Security, Monitoring 
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Software Library 





Backup § Restore 
Administration 
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Security 
Management 


Storage 
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Storage Management Infrastructure 


Management 


NN 


b 
[a 


ne azonban teljes, ha nem említenénk meg, 
mely témákról és technológiákról nem esik 
benne szó. A WSSRA kizárólag a központi 
infrastruktúra vonatkozik, és nem ejt egyet 
len szót sem a kliensoldali technológiákról, 
sem a Windows XP-ről, sem az Office 2003- 
ról, sem az SMS-ről nem készült implemen- 
tációs útmutató. Sőt, még a felhasználók- 
nak kiajánlott , lerminálszerver" szolgáltatás 
sincs a rendszerben, hisz az nem más, mint 
egyfajta klienstechnológia. A , Deployment 
Services" fejezet is csak a kiszolgálók automa- 
tizált telepítésével foglalkozik, a kliensekével 
már nem. 

A teljes csomag elkészítése, tesztelése hosz- 
szú időt vett (vesz) igénybe, így a nagyon 


gyorsan változó [I[-világot egy kis lemara- 


Services 


MOM . MOM 
DCAM  DCAM 


dással követi. Nem fogunk utalást találni a 
Windows Server 2003 R2 újdonságairól, és 


Tools/Debug 
HW Mgmt 
Remote Admin 


Definitiíve 
Software 
Library 


Storage 
Tools 


Backup 
Restore 








Network Devices 








Centralized Data Center Servers 


Client Worksations/Devices 


SAN Storage Devices 











A rendszermenedzsment sematikus váza a Management Architecture Blveprintben 


alio különbözik Sakát" magyvallalatról "akát 
középvállalatról van szó. A szolgáltatások szá- 
ma szinte ugyanannyi, a problémák hason- 
lóak, és láthattuk, hogy ugyanúgy szükség 
van standardizálásra, méretezésre, biztonsá- 
gi intézkedésekre, jól definiált üzemeltetési 
eljárásokra. Ezek mind-mind megtalálhatók 
a WSSRA-ban, olyan példaként, amely ala- 
pul szolgálhat, és amelyet felhasználva gyor- 
sabban és semmit ki nem felejtve hajthatók 


végre a helyi projektek. Ha csak a WSSRA 


NY TT etánt Te tat 





A WSSRA dokumentumcsomag elérhető innen: 
http://www.microsoft.com/hun/windowsserver- 
system Refarchy default.mspx 





alapjait alkalmazzuk, már akkor is egy szab- 
ványosított ILinfrastruktúrát hozhatunk lét 
re, amely rengeteg II-problémától megszaba- 
díthat minket - legfőképpen csökkenti, csök- 
kentheti a tűzoltó munkát az értelmes fejlő- 
dés javára. Aki viszont a részletekbe menően 


mintaként tekint a ,mintamegoldásra", az 


1 


megfelelő szolgáltatás , Operation Guide" Ját, 
és máris látni fogjuk! És mindezt nem csak a 
Windowsra vonatkozóan. 

Ott találjuk majd a hálózat, a storage, a 
szerverhardver leírását is. Végeredményben a 
WSSRA egy példán keresztül a tervezési, te- 
lepítési és üzemeltetési szaktudás transzferét 
jelenti. Pontosan azt, amire egy középválla- 
lat erőforrás-hiányos [I-csapatának a legna- 


gyobb szüksége van. 


egyelőre adós a megoldás a szervervirtuali- 
zációs módszerek alkalmazásának bemutatá- 
sával is. A Microsoft akvizíciós tevékenysége 
felgyorsult az utóbbi időben, és számos olyan 
vállalat (Sybari, Softricity stb.) került a szoft 
veróriáshoz, ahol korábban és most is meg- 
határozó infrastruktúramegoldásokat állítot 
tak elő. Ezeket a szoftvereket nem volt alkal 
ma a WSSRA tt készítő csapatnak beépíteni a 
referenciarendszerbe, így mi sem juthatunk 
innen tapasztalatokhoz róluk. Remélhetjük 
viszont, hogy a Longhorn generációhoz meg- 
jelenő referenciarendszer már egy részüket 
beépíti majd, demonstrálva az integrációból 
fakadó előnyöket. 

Mindent egybevetve kijelenthetjük: a Win- 
dows Server System Reference Architecture 


az eddigi legtejesebb, nyilvánosan dokumen- 





A dokumentáció tartalmaz egy 
ábrát, amely az általános II-projekt 
költségeit ábrázolja WSSRA-segédlet 
tel és anélkül. Mivel van, amit már 
más kitalált, felépített, megvalósított, 
ezért annak átvétele, testre szabása 
jóval kevesebbe kerül, mintha ez ma- 


gunknak kellene kitalálni. Amikor 





GCustomization 
HWSSRA 


Project 1 


Project 2 








egy nagyobb projektet tervezünk, na- 
gyon is konkrét, pénzbe kerülő mér- 
nökórákat takaríthatunk meg a módszerek 
átvételével ahelyett, hogy mindent magunk 
találnánk kie 

Ezaz írás atta óuzdít hogy batran eljünk 
azokkal a mérnöki dokumentációkkal, ame- 


lyeket kifejezetten nekünk írtak. Nem len- 


Egy projekt költségei WSSRA-val és nélküle 


tált mintarendszer, amely hosszú-hosszú ideig 
szolgálhat nagy és apró ötletekkel az azt for- 
gatók számára. 
Kellemes olvasgatást! 
Lepenye Ilamás 
(tamaskemicrosoft.com) MCSE, Microsoft Magyarország 
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TERVEZZ MERÉSZEN! 





CNN NR 


Sokan azt gondolják, hogy a szerverparticionálás 


a nagyvállalatok játékszere. Ez egyáltalán nem így van. 


A virtualizáció olyan lehetőségekhez juttathatja a kis- és közepes 


vállalatokat, amilyenekről eddig csak álmodni lehetett. 


együk fel, hogy egy ügyfélnél 30-50 felhasználó dolgozik egy hálózatban. Egyetlen telep- 
hely, szokásos igények: fájl: és nyomtatószolgáltatás, levelezés és csoportmunka, tűzfal, 
esetleg egy kliens-szerver alapú mini-ER P. 

A nem túl nagy, de jól prosperáló és innovatív cég megfogalmaz , néhány" elvárást. A szol 
gáltatás legyen zökkenőmentes, és amennyire lehet, folyamatos. Az egyik szolgáltatás ne zavar- 
ja a másikat. Az infrastruktúra legyen biztonságos és naprakész, és bárhonnan, akár otthonról 
is elérhető. Legyen minden egyszerű, hogy bárki átláthassa: nem szeretnének egyetlen külső 
szolgáltató szervezettől sem függeni, sokkal inkább versenyeztetni lenne szerencsés őket. A 
mentésről is gondoskodni kell, sőt megoldás kellene az esetleges katasztrófák ellen. Ne legyen 
sok szerver, mert azok rengeteg pénzbe kerülnek, sokat fogyasztanak, és drága lenne hozzájuk a 
megfelelő áthidalást biztosító szünetmentes tápegység, a hűtésről már nem is beszélve. És még 
két apróság: a cég adatbázisokhoz fejleszt szoftvereket, és a teszteléshez szükség van minél több- 
féle adatbázisra, lehetőleg úgy, hogy egymást a lehető legkevésbé zavarják. Ezen felül néhány 
munkatársnak okostelefonja van, az e-maileket szeretnék azokon is olvasni. Három szerverrel 
mindez megoldható, ugye? 

Ha most valaki széttárja a kezét, és azt mondja, hogy nem, akkor kellemesen fog , csalód- 
ni": igenis, három, okosan méretezett szerverrel mindez megvalósítható. Kezdjünk tervezni, 


és meglátjuk! 


Szolgáltatásleltár 

Mindenekelőtt vegyük sorra, milyen szolgáltatásokat kell biztosítania a rendszernek a felhasz- 
nálók számára: 

m fájl és nyomtatószolgáltatás; 

nm levelezés; 

m internetelérés; 

m betárcsázás/ VPN; 

nm üzleti alkalmazás elérése (mini-ER P); 

an hozzáférés adatbázisokhoz a szoftverek teszteléséhez. 

Vegyük sorra, mindehhez milyen háttérszolgáltatásokra van szükségünk (itt a , háttérszolgál 
tatás" nem minden esetben azonos a Windows-kiszolgálók , szolgáltatás" (service) fogalmáva)): 
a címallokáció és névfeloldás: DHCP, DNS WINS; 

m címtár (Active Directory); 

a RADIUS(IAS); 

nm elosztott fájlrendszer (DF9); 
um szoftverfrissítés: WSUS; 

m antivírusrendszer; 


u mentés; 
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an Management SOL; 
a rendszerfelügyelet (MOM); 
an tűzfal; 
an tanúsítványszolgáltatás. 
Az elvárásokból nem lehet ugyan kiolvas- 
ni, de bizonyosan szükség lehet operációs 


rendszerek és alkalmazások telepítésére is. 


Biztonság, rendelkezésre állás 

A biztonságos rendszer követelmény, már- 
pedig biztonsági sablonokat akkor tudunk 
hatékonyan létrehozni, ha egy, vagy csupán 
néhány szolgáltatás fut egy kiszolgálón. Itt 
az egyik látható és feloldandó ellentmon- 
dás: adott rengeteg elvárt, igényelt funkció, 
ugyanakkor nagyon kevés a rendelkezésre 
álló hardver. 

Az ügyfél megfogalmazott folyamatos szol 
gáltatási igényt. Kisvállalatról lévén szó, itt el- 
sősorban az alapszolgáltatások (DHCP, DNS, 
WINS, AD, IAS) redundanciájának megva- 
lósítása jöhet szóba. Ez azonban tovább ne- 
hezíti a feladatot: a duplikálás szaporítja az 
elhelyezendő szolgáltatások számát. 

Összességében tehát hat felhasználói szok 
gáltatás, tizenkét háttérszolgáltatás és öt tar- 


talék-háttérszolgáltatás biztosítása a feladat. 


A szolgáltatások csoportosítása 
A Small Business Server jellegű rendszerek 
szélsőséges módon bizonyítják, hogy néhány 
ritka kivételtől eltekintve szinte minden szol 
gáltatás együtt futtatható más szolgáltatások- 
kalsezra gyakorlat azonban több problémát 
is felvet: 

I. Teljesítmény. Ha a szolgáltatások azo- 


nos típusú erőforrást (például memóriát) na- 


Le 
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gyobb mértékben igényelnek, akkor együttes 
futtatásuk teljesítményromláshoz vezethet. 
II. Kompatibilitás. Egy adott szolgálta- 


tás ás szolgáltatás tuttatását kizát 


és szigorúbb biztonsági sablonokat alkalmaz- 
hatunk, mint tennénk azt egy SBS-megoldás 


esetén (0 százalékos szolgáltatásizoláció). 





hatja 

III. Biztonság. Egy szolgáltatás 
olyan beállításokat igényelhet, amely 
egy másik biztonságosságát csök- 
kentheti. Több szolgáltatás futtatá- 
sa nagyobb támadási felületet jelent. 
Szeparálás esetén egy esetleges be- 
hatolás csak egy-egy funkciót érint, 
nem többet. 

IV. Karbantartási idő. Egy szol 
gáltatásra szükség lehet, miközben 
egy másik karbantartása miatt állni 
kényszerül. 

A fenti problémák kezelésére az 
általános megoldás a szerepkörök 
szerinti rendszerfelépítés. Ha egy ki- 
szolgálónak csak egy (vagy néhány 


logikailag összeillő) meghatározott 





szerepköre van, akkor biztonsági sab- 











lonokkal menedzselhető, tehát álla- 
pota pontosabban definiálható és 
jobban megőrizhető. Egy tartományvezérlőn 
például szigorúbb biztonsági sablonok ér- 
vényesíthetők, ha nincs más funkciója. A 
levelezőkiszolgálók biztonsági beállításairól, 
ha csak ez az egyetlen funkció a szerveren, 
tucatnyi dokumentáció áll rendelkezésre, de 
más szolgáltatásokkal együtt már nekünk 
magunknak kell kitalálnunk, miképp legyen 
ténylegesen a lehető legbiztonságosabb. 
Biztonságos, a legjobb gyakorlat elvét nem 
megsértő módon is lehetséges a szolgáltatások 
csoportosítása - a különböző Security-útmu- 
tatók ezekre felkészülnek. A mi példarendsze- 


rünkre egy lehetséges csoportosítás az alábbi: 


I. Fájk és nyomtatómegosztás, DES 

II. Levelezés 

III. Tűzfal (vírusfal), betárcsázás, VPN 

IV. Üzleti alkalmazás, SOL 

V. Tesztadatbáziskezelők szoftverteszteléshez 
VIDAD TAS DECPSDNS WINS ELST 
D97006KEZEMÉSSS B EKE PSZS SZSSSE 
ve WINS-2 

VIIL Management SOL, WSUS, mentés, an- 
tivírus, MOM, RIS 


Úgy tűnik tehát, hogy a szélsőségek elke- 
rülhetők. Nem szükséges 16 kiszolgáló be- 


szerzése (100 százalékos szolgáltatásizoláció), 
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1. ábra. A szolgáltatások függőségi viszonyai 


A nyolc csoport ugyanakkor nyolc szervert 
is jelentene, ez pedig még mindig nem elégíti 


ki a követelményeket. 


Függőségek 
Mielőtt a fenti nyolcas csoportot valahogy 


hárommá gyúrnánk össze, érdemes felvá- 


gondoskodnunk kell arról, hogy előbb azok a 
service-ek induljanak, amelyektől a többiek 
függnek. (Az I. ábrán látható struktúra ak: 
kor igaz, ha a szolgáltatásokat Microsofttech- 
nológiákkal valósítjuk meg. Minden kompo- 
nenst csupán egyszer tüntettünk fel.) 

Nem állítható, hogy minden egyes apró- 
SáDOL tattalmazraz a áldras de Faz jollátszikó 
hogy mindössze négy alapszolgáltatás (DNS, 
WINS, DHCP, AD) indulási prioritását kell 


biztosítani. 


A szerver—hardver problémája 
Minden valamirevaló rendszermérnök tudja, 
hogy a mai processzorokkal szerelt szerver- 
gépek számítási teljesítménye kis felhaszná- 
lószám esetén nem gazdaságos: nem tudunk 
ISO brocesszort vásárolni holott aünyi 
is elég lenne. A korszerű gépekre ugyanakkor 
szükség van: a menedzsment, a távolról való 
vezérlés, a távolról való diagnosztizálás a leg- 
korszerűbb eszközökben a legkifinomultabb, 
és persze a szerver élettartama is akkor a leg- 
hosszabb, ha új gépben gondolkodunk. 
Vegyük emellett számításba, hogy a me- 
mória - szemben a korábbi évekkel - sok 
kal inkább megfizethető, továbbá már 5-6 
lemezből is terabájtos tárolót lehet összeállí 
tani úgy, hogy szó sincs még SAN építéséről. 
Látható az is, hogy mára egyetlen , egyszerű" 
szerverben olyan kapacitások és képességek 
halmozódnak fel, mint korábban egész adat 


központokban. 














Rakjuk össze a mozaikokat: 
adott egyik oldalon egy sokszer- 
veres - jelen esetben éppen nyolc 
szerveres - igény. Adott továbbá 
egy olyan kiszolgáló, amely eleve 
többletkapacitással — vásárolható 
meg. Szinte adódik az ötlet, hogy 
, vágjuk fel" az oszthatatlannak 
tűnő szerver-hardvert valamivel. 
Ez a felvágás, felosztás a szerver- 
particionálás, más néven virtua- 
lizáció. Az eszköz pedig lehet pél 
dául egy Microsoft Virtual Server 
2005 RZ2 szoftver. 


Ha egyetlen kiszolgálót virtuá- 








2. ábra. Függőségek Virtual Serverrel 


zolni a szolgáltatások egymástól való függő- 
ségét. Ez azért fontos, mert amikor majd a 


rendszer leállását/indulását tervezzük, akkor 


lisan több részre osztunk, akkor 
gazdaságossá válhatnak olyan be- 
ruházások, amelyek egyébként 
számosságuknál fogva nem lennének azok. 
A kiszolgálók környezetét és magukat a szer- 


vereket úgy tervezhetjük, hogy minél keve- 
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sebb leállás történjék akár tervezetten, akár 
váratlanul. Az ilyen vállalatméretnél gazda- 
ságos megoldás lehet a kettős tápellátás; segít 
a menet közben cserélhető merevlemezek, a 
hardveres RAID-védelem és a memória meg- 
hibásodása ellen védő ECC vagy Chipkill 
technológia beépítése, betervezése. Mindezt 
pedig csak egyszer (vagy néhányszor) szük- 
séges megvenni, nem pedig nyolcszor, mi- 
közben minden partíció rendelkezésre állása 
növekedhet. 


A virtualizáció és hatása a tervezésre 
Ha amellett döntünk, hogy a megoldás része- 
ként virtualizációs technológiát is alkalma- 
zunk, egy újabb réteget, újabb szolgáltatást 
építünk a rendszerünkbe. A Microsoft Vir 
tual Server 2005 R2 akkor menedzselhető 
hatékonyan, ha tartományban üzemel, ezért 
módosítanunk kell az 1. ábrát, méghozzá a 2. 
ábrán látható módon. 

Mindebből úgy tűnik, az alapszolgáltatá- 
sok nem virtualizálhatók, hiszen maga a 
szerverparticionálás is (hangsúlyozandó: tel 
jes funkcionalitás esetén!) az alapszolgáltatá- 
soktól függ. 

De nem ez az egyetlen probléma. Az egyes 
partíciók meghatározott és meglehetősen kö- 
tött virtuális hardvereszköztárral rendelkez- 
hetnek, s ezek között nem található szalagos 
egység sem. Amennyiben nem szeretnénk 
lemondani erről a tárolási típusról - és má- 
sodlagos tárolóként bizony nagyon fontos a 
katasztrófavédelem szempontjából is -, kény- 
telenek leszünk a mentési szolgáltatást ki- 
emelni a virtualizáció , alól". (Elvileg nem le- 
hetetlen szalagos egység használata virtuális 
gépekben sem iSCSI segítségével. Az iSCSI 
alapú szalagos egységek ára azonban jelenleg 
nem teszi lehetővé, hogy az üzleti megoldás- 
nál figyelembe vegyük őket.) 

A szolgáltatáscsoportokat, a redundanciát, 
a függőségeket és a virtualizáció hozta továb- 
bi elvárásokat figyelembe véve a 3. ábrán lát 
ható logikai rendszerfelépítés lehet az egyik 
megoldása az ügyfél igényeinek. 

Az első szerver alapszolgáltatásokat is 
nyújtó tartományvezérlő, amely emellett ta- 
núsítványkiszolgáló feladatot lát el. A ha- 
sonlóan szigorú biztonsági előírások miatt 
célszerű a szolgáltatások ilyen csoportosítása. 
Teljes rendszerindulásnál ez az első kiszolgá- 
ló, amely elindul, biztosítva a másik kettő és 


a virtuális szerverek számára a névfeloldást 


tata EN NAg Há d, 


és a hitelesítést. A második kiszolgáló egy de- 
dikált szerver, amely kizárólag virtuális rend- 
szerek futtatását végzi. Összesen hat partíciót 
tartalmaz, és a korábban már meghatározott 
szolgáltatáscsoportokat futtatja egy-egy vir- 
tuális gépben. 

Végezetül a harmadik rendszer menedzs- 
ment és egyéb háttérszolgáltatásokat végez, 
többek között a mentést, a szoftverfrissítést 
és a központi antivírus-feladatokat. 

Nézzük az igények teljesülését. A rendelk 
kezésre állást a kevés fizikai eszközben érvé- 
nyesített hardverredundancia, valamint az 
alapszolgáltatások megkettőzése biztosítja. A 
szolgáltatások előírás szerint elválasztottak, 


a rendszert ,konzerv biztonsági sablonok" 


CNN NR 


ges katasztrófák esetén is védelmet nyújthat. 
Felhasználói adatokat kizárólag a Server2 tar- 
talmaz, ez megint csak a mentés konfigurá- 
lását egyszerűsíti. TIeljesült a háromszerveres 
kritérium is, a megoldás akár 4U rackmagas- 
ságban is elhelyezhető. Ez végeredményben 
kisebb hűtési kapacitást és kisebb szünet 
mentes tápegységet igényel. 

A megoldás még három járulékos előnyt 
hordoz. Amennyiben a Server2 operációs 
rendszere Windows Server 2003 R2, a hat 
virtuális gépből négynek az operációs rend- 
szeréért nem kell külön fizetni. 

Bár a 3. ábra csak egyetlen tesztjellegű 
SOL-kiszolgálót jelez, de a cég tevékenysé- 
géből adódik, hogy akár több ilyen virtuá- 

lis gépre is szükségük lehet. A 





Virtual- 
Server1 


Server3 


Víirtual- 
Server4 


Virtual- 
Server5 


Víirtual- 
Server6 








Microsoft licence lehetővé teszi, 
hogy korlátlan számú lekapcsolt 
virtuális géppel rendelkezzünk, 
s csupán azokért kell fizetnünk, 
amelyeket ténylegesen haszná- 
lunk, elindítunk. 

Ez pedig sarokpontja lehet a 
megoldásnak. Hat-nyolc teszt 
gép esetén ugyanis már bizo- 
nyos, hogy a hardver: és szofítver- 
átaksa vittualizációt alkaldátazó 
megoldást teszik olcsóbbá. 

Végezetül egy majdani hard- 
METESETE A SENYELL ESETEM MEN 
állarajdtmtássól Ain a virtuális 
gépek lemezeinek másolásából, 
ami jelentős idő- és költségmeg- 
takarítást eredményez. 

Ennek a rövid példatanul 
mánynak a célja elsősorban az 
volt, hogy megmutassuk, miként 


befolyásolhatja a tervezés mene- 





tét a virtualizáció alkalmazása. 





3. ábra. Szolgáltatások három fizikai szerveren 


gyors testreszabásával lehet megerősíteni. A 
szoftverfrissítés nagy részét elvégzi a WSUS. 
Az ISA szerver révén a rendszer bárhonnan 
elérhető (RASZVPN). Az okostelefonokat az 
Exchange 2003, az ISA 2006 és a CA-szer- 
ver együttesen kiszolgálja. A Virtual Server 
2005 R2 a Volume Shadow Copy igénybe- 
vételével hamarosan képes lesz a virtuális 
szerverek lemezeinek mentésére (harmadik 
gyártótól származó mentési rendszerrel). A 
mentések és a virtuális gépek rendszerpartíci- 


óinak szalagra másolásával a megoldás tényle- 


Az információs rendszerek ter- 

vezésekor gyakran egymásnak el 
lentmondani látszó igényeket kell és - ahogy 
láthattuk - lehet kielégíteni. 

A valóságban a tervezés itt nem állhat le, 
hiszen az eszközök fizikai kialakítása, mére- 
tezése, adott esetben teljesítménymutatóik 
előrejelzése, nem utolsósorban pedig teljes 
birtoklási költségük becslése, más alternati- 
vákkal való összevetése mind-mind a beruhá- 
zási döntést megelőző tevékenységek. 

Jó tervezést! 

Lepenye Ilamás 
(tamaskemicrosoft.com) MCSE, Microsoft Magyarország 
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ISA Server 2006 


— a hitelesítéssel kapcsolatos újdonságok. 


zeptemberben jelent meg az ISA-kiszolgálók harmadik generációs képviselője, az ISA 

Server 2006. Megjósolható volt ugyan, hogy első ránézésre drasztikus változást nem fo- 

gunk tapasztalni az előző verzióhoz képest, de ha kicsit alaposabban megvizsgáljuk, ak- 
kor azért több fontos, hasznos és nagyléptékű újítást is felfedezhetünk. 

Egyelőre viszont csak egy témakört érdemes kiemelni szélesebb áttekintésre, és ez a hitelesí- 
tés vagy más szóval az autentikáció. Rögtön a témába vágva, nézzük meg, hogy egy ISA Server 
esetén milyen fő szakaszokra osztható a hitelesítési procedúra: 
an a kliens jogosultságainak elfogadása; 

a a jogosultságok érvényesítése, amelyhez egy hitelesítésszolgáltató szükséges (például Active 

Directory, RADIUS, SecurID); 

m a hitelesítési adatok delegálása egy, az ISA , mögött" működő szerver (például egy SharePoint 

Portal Server) közreműködésével. 

Az első két komponenst az adott listener (az ISA egy-egy, a beérkező kéréseket figyelő , füle") 
segítségével konfiguráljuk, míg a harmadikat a vonatkozó publikálószabályban. Ez egyúttal 
azt is jelenti, hogy ugyanazt a listenert természetesen használhatjuk több publikálószabályhoz 
is, sőt esetenként változó delegálási típusokkal is. Ezek után viszont tekintsük át csoportokba 
szedve az összes, ISA Server 2006-ban megtalálható hitelesítési technológiát és módszert. 

1. Nincs hitelesítés 

2. HTML űrlap alapú klienshitelesítési metódus 

x Windows (Active Directory) 
an [LDAP (Active Directory) 

a RADIUS 

a RADIUS OIP 

mi RSAT Seeed 

a SSO 

3. HITP alapú klienshitelesítési metódus 

nm Basic 
a  Digest/wDigest 
a Integrated 


4. SSL klienstanúsítványon alapuló hitelesítés 


Urlap alapú hitelesítés (Forms-Based Authentication) 
Egyre több olyan webes alkalmazás, szolgáltatás jelenik az intranet/internet/extranet hálóza- 
tokban, amelyek miatt biztonságos, részletesen szabályozható és testreszabható hitelesítési for- 


mákat kelllene) alkalmazni. Az intranet szó nem elírás, tényleg komolyan el kell gondolkoznunk 


16 
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azon, hogy a belső felhasználók, valamint a 
vezetékes vagy vezetéknélküli , alkalmi" kap- 
csolódók (szállítók, vendégek, ügyfelek, a lap- 
topokkal, PDA-kkal stb.) azonosítás és hi 
telesítés nélkül érhessékre el a belső hálózat 
eleddig semmilyen módon nem korlátozott 
erőforrásait (webszerverek, portálok stb.). 

Az ilyen típusú igények megjelenése miatt 
az ISA 2006-ban gyakorlatilag bármilyen 
webszerverpublikálásnál használhatjuk az 
FBA-t, három fő csoportba osztva: 

mx jelszó-űrlap:  felhasználónév/jelszó, az 
Active Directory, az LDAP és a RADIUS- 
jogosultságok ellenőrzésére; 

x passcode-űrlap: felhasználónév/passcode, 
a SecurelD- és a RADIUS-hitelesítésnél; 

a passcode/jelszó-űrlap:  — felhasználónév/ 
passcode a hitelesítésre és felhasználónév/ 
jelszó a delegálás céljából. 

Az űrlapos hitelesítés további újdonságai 
közül az egyik legfontosabb a jelszókezelés. 
Ez azt jelenti, hogy újra lehetőségünk van a 
felhasználók számára megengedni, hogy akár 
távolból is megváltoztassák a jelszavukat, va- 


lamint azt is elérhetjük, hogy az általunk be- 


[egász sel Ási A 
[ddcziaaleekize [gas ő 
Acceleration Server 2006 


Security ( show explanation ) 


9 This is a public or shared computer 

9 This is a private computer 
Warning: By selecting this option you acknowledge that 
the computer complies with your organization s security 
policy. 


I want to change my password after logging on 
Mith tt jeld eli elected, a age used to cha arzdát (elb 


pie VESE a falatraxtgjakab 


Password: 
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Egy szimpla weboldalhoz tartozó hitelesítés 
jelszóváltoztatási kéréssel 


állított időhatáron belül a jelszóváltoztatás 
szükségességéről értesítést (lés ennek apro- 
póján rögvest egy jelszóváltoztató űrlapot is) 
kapjanak. A két opció nem szükségszerűen 
jár együtt, szerencsére külön-külön is szabá- 


lyozhatóak. 


További megjegyzések és tudnivalók 
az űrlap alapú hitelesítésről 
a Az ISA Server 2006 képes ezt a hitelesítési 


formát a mobilkliensek számára is bizto- 


Microsoft TechNet 
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sítani, persze csak akkor ha a mobilesz- 
közről beérkező kérés User-Agent fejléce 
alapján megfelelően detektálta a klienst. 
Az ide tartozó űrlapok az ISA telepíté- 
si mappájának MCookieAuthlemplatesv 
ISANCHTML illetve XHTML mappájá- 
ban találhatók meg. 

a Közvetlenül ide tartozik még az is, hogy a 
szimpla HI ML-űrlapokat is teljesen testre 
lehet szabni, a telepítési mappa Cookie- 
Authlemplates könyvtárában immár két 
almappa van: egy Exchange nevű, amely- 
ben az eddig is ismert módon lehetséges az 
OWA FBA logon képernyőt testreszabni, 
és a már említett ISA nevezetű, amely az 
alap HIML-logon képernyő elemeit is tar 
talmazza, például az összes szöveges részt a 
Strings.txtben. 

nm Az ISA Server 2006 összesen 26 külön- 
féle nyelven képes megjeleníteni ezeket 
az! űrlapokat," szintem" egy! vizssálat Paz: 
az a böngésző nyelvi beállításai alapján. 
Természetesen ettől eltérő beállítást is 

megtehetünk a publikálószabályon belül 

(Listener/Properties/ Forms), azaz elkép- 

zelhető olyan felállás is, hogy más lesz az 


űrlap és más a böngésző nyelve. 


550 


Mivel egyre nő a publikált szolgáltatások 
száma, könnyen elképzelhető, hogy egy szer- 
vezeten belül több különböző erőforrást is 
szeretnénk , megmutatni" a külső felhasz- 
nálóknak. Ez rendben is lenne, de azonnal 
adódik egy probléma is: mégpedig az ismételt 
bejelentkezések szükségessége. 

Ezzel lényegében el is értünk az SSO 
(Single Sign-On, egyszeri belépés) módszer 
alkalmazásához, amelynek a lehető legtöbb 
esetben együtt kell érvényesülnie az új hitele- 
sítési megoldásokkal, mert különben - első- 
SOrdan a jelhasználók számátas s magyon fás 
rasztóvá válhat egy-egy belépési folyamat. Ezt 
az opciót az ISA Server 2006-ban immár egy 
külön panelen találjuk az adott listener tulaj- 


donságai között. 


Multifaktoros hitelesítés 
Teljesen egyértelmű, hogy a hitelesítési folya- 


matnak igazán biztonságosnak kell lennie, 
de hogyan lehet még jobban fokozni a biz- 
tonságosságot? Erősebb titkosító kulcsokkal, 
bonyolult, gyakran változó jelszavakkal, pub- 


likus és privát környezetben eltérő módon 
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működő környezeti beállításokkal? Igen-igen, 
de mégsem csak így. Ha viszont másfelől kö- 
zelítünk, és a többszörös hitelesítést, vagyis 
az úgynevezett multifaktoros módszert al 
kalmazzuk, akkor valószínűleg nagyobbat lé- 
pünk előre. Miről van szó? 

Például az ISA Server 2004-ben bemutat 
kozó és az ISA 2006-ban alaposan kibővített 
kétfaktoros hitelesítésről, amely a felhaszná- 
lót kettős hitelesítésre kényszerítheti, azaz 
egy user/password kombináció, valamint egy 
hardvereszköz vagy egy tanúsítvány , bemu- 
tatáasára . 

A lehetséges variációk szerint a felhaszná- 
lónak rendelkeznie kell: 

a egy tanúsítvánnyal; 
a vagy egy egyszeri jelszót/ kódot (One-time 
password, OTP) generáló szoftveres mo- 


dullal/hardvereszközzel; 


edesllg ő 
[desaalkizze tg as 
Acceleration Server 2006 


Security ( show explanation ) 


9 This is a public or shared computer 
9 This isa private computer 


Remote Access Credentials ( 


j) user name ar PF: 


7-1diat- han: Hi gjakab 
Passcode: 
Internal Network Credentials ( hide explanation ) 
del day Yen zapoAi ég ; jézbk 12 
TA Use a different user name 


Domainluser name: Ezeket dee 


er ecrtieleb 
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Űrlapos, dupla hitelesítés 


a vagy egy SecurID-eszközzel, amely minden 
szükséges esetben (hosszú érvényességi 
időben, például 23 évig) egy úgynevezett 
passcode-ot (nagyon rövid lejáratú szám- 
kombináció) képes generálni. 

Tipikus példa, hogy a felhasználó rendelk 
kezik egy smartcardon elhelyezett személyes 
tanúsítvánnyal, amelyet az ISA ellenőrizhet 
a belső hálózatban elhelyezett CA-kiszolgáló 
segítségével, és ha pozitív a vizsgálat ered- 
ménye, akkor biztonságosan hitelesíti a fel- 
használót: 

Még két gondolat a multifaktoros hitelesí- 
tés alkalmazásához az ISA 2006-ban: 


CCA NP 


a az űrlap alapú hitelesítés teljeskörűen 
együtt használható ezzel a módszerrel; 

a az OTP az ISA 2004-ben maximum a 
SecurID megoldáshoz volt alkalmazható, 
mostantól viszont a RADIUS hitelesítésé- 


nél is támogatott. 


Hitelesítésdelegálás 

Egyre több esetben fordul elő, hogy a háló- 
zatokat elválasztó elemnek, azaz a tűzfalnak 
kell az elsődleges ellenőrzést elvégeznie, azért 
is, hogy a belső hálózatban működő kiszolk 
gálót ne terheljük, és ne kockáztassuk az ál 
lapotát, például egy , próbálgatós" kedvű, az 
OWA-ba jogosultság nélkül belépni óhajtó 
internetes vendég miatt. 

Maradva a példánál: sokkal jobb, ha a tűz- 
fal Exchange szervernek , hazudja be" magát, 
és már a határvonalon visszautasítja a jogo- 
sulatlan elérést, mint ha minden hitelesítési 
csomagot előzetes vizsgálat nélkül, nyomban 
továbbítana az Exchange szervernek. 

Ezért van az, hogy egy - az ISA kiszolgálón 
keresztüli - hitelesítési folyamatban csak a jo- 
gosultságok érvényesítése után következik a 
jogosultsági adatok végleges ellenőrzése, ame- 
lyet delegál az ISA a megfelelő belső szerver 
felé. Viszont ezzel kapcsolatban is van fontos 
változás, mert míg az ISA Server 2004-ben 
csak a Basic hitelesítésénél élt ez a lehetőség, 
a 2006-os verziónál a Digest, az Integrated 
és a SecurID hitelesítési metódusnál is alkal 
mazható. 

Sőt, a publikálószabályoknál a következő 
lehetőségeink vannak még ezeken kívül is: 

a nincs delegálás és a kliens nem hitelesíthet 
közvetlenül; 

a nincs delegálás, de a kliens hitelesíthet 
közvetlenül; 


a kikényszerített Kerberos-delegálás. 


A jogosultságok tárolása 
Az ISA Server 2006 képes tárolni a Basic 
és az űrlap alapú hitelesítésnél használt fel 
használói adatokat. Ha kérjük ezt a lehető- 
séget (alapértelmezésben tiltva van), akkor 
az ISA egy ICP sessionben egyszer, és kizá- 
rólag csak a legelső HTITP-kérés alkalmával 
követeli majd meg ezeket az adatokat. Ezt a 
módszert az Integrated (az AD és az LDAP- 
féle egyaránt) és a RADIUS hitelesítési mód 
is támogatja. 
Gál Iamás 
(gtamascotiszki.hu) MCSE, MCSA, MCT, MVP 
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VISSZAÁLLÍTÁS 





Egyre több, kritikusan fontos adatot tárolunk a számítógépeinken. 


Legyen szó akár egy önálló otthoni számítógépről vagy egy 


bonyolult informatikai rendszerről, elengedhetetlen, hogy biztosítsuk: 


a benne tárolt adatok ne vesszenek el. 


ritikusan fontos adatok nem veszhetnek el! Ennek a követelménynek a megvalósításá- 
hoz legfontosabb elem az, hogy rendszeres, megbízható adatmentéssel rendelkezzünk. 
Bár ezen a téren a Windows Vista és a , Longhorn" Server jelentős újdonságokat fog 
felmutatni, érdemes megnézni, hogy milyen eszközök állnak már most rendelkezésünkre a 
Windows Server 2003-ban. Ebben a cikkben a mentés és visszaállítás alapvető tervezési kérdé- 
seinek áttekintésén túl bemutatunk előre elkészített scripteket is a mentési folyamat automati- 


zálásának megkönnyítésére. 


Tévhitek 


Először azonban érdemes megismerkedni néhány tévhittel a mentéssel kapcsolatban: 

, Megfelelő redundáns lemez-alrendszerrel rendelkezünk, tehát nem fordulhat elő adat 
vesztés." Ez az elképzelés alapjaiban téves. A mentést nem helyettesíti semmi. Egy redundáns 
rendszer növeli a rendelkezésre állást, ugyanakkor nem nyújt megoldást több előforduló prob- 
lémára: 

x adatok véletlen vagy szándékos törlésére; 
nm szoftverhibából adódó adatsérülésre; 

a külső támadásra (cracker, vírus stb.); 

an katasztrofális hardversérülésre. 

, Van mentésem, tehát biztonságban vagyok." Ebben az esetben feltehetjük a kérdést: meg- 
próbálta valaki, valamikor azt a mentést visszatölteni? 

Vegyük tudomásul: az, hogy beállítottuk a rendszeres mentést, nem garancia arra, hogy ezt 
vissza is tudjuk állítani. A mentést rendszerben gondolkodva kell felépítenünk. Ennek a folya- 
matnak elengedhetetlen része a tesztelés. Nemcsak a mentést magát kell tesztelnünk, hanem a 


visszaállítást is. Ez a gondolat rögtön elvezet a mentési rendszer tervezése felé. 


Tervezési szempontok 

Ahhoz, hogy biztonságban érezhessük magunkat, el kell készítenünk és tesztelnünk kell egy 
katasztrófatervet. Ez a terv tartalmazza azokat a feladatokat, folyamatokat, amelyek képessé 
tesznek bennünket arra, hogy egy komoly rendszerhiba esetén, a legrövidebb időn belül újra 
működőképessé tudjuk tenni a rendszerünket, és biztonsággal vissza tudjuk állítani adatain- 
kat. Néhány alapvető fontosságú szempont, amelyet figyelembe kell vennünk: 


Mentési ablak. Az az idő, ami napi, heti rendszerességgel rendelkezésünkre áll a mentés le- 


R. 


futtatására. Manapság egyre nagyobb adat 
mennyiséget kell egyre rövidebb idő alatt 
menteni, ezért a mentési ablak gondos terve- 
zést és tesztelést igényel. 

Visszaállítási idő. Már a mentés terve- 
zésénél figyelembe kell vennünk, hogy egy 
meghibásodás esetén mennyi idő alatt le- 
szünk képesek működő állapotba visszaállí- 
tani rendszerünket. Ahogy a vállalkozások 
működésük során egyre jobban támaszkod- 
nak az informatikára, egyre kevesebb az az 
idő, amit képesek működő számítógépek nél 
kül átvészelni. 

Mit mentsünk, milyen rendszerességgel? 
Az informatikai rendszer felépítésekor végig 
kell gondolnunk, hogy milyen adataink, mi- 
lyen rendszerességgel változnak. Mik azok 
az adatok, amelyeknek online elérhetőeknek 
kell ugyan lenniük, de esetlegesen már csak 
olvasásra használjuk őket, valamint hogy me- 
lyek azok az adatok, amelyekre csak ritkán 
van szükség. Egy ilyen jellegű adatelemzés 
nagymértékben segítheti a mentés tervezé- 
sét, csökkentheti mind a visszaállítási időt, 
mind a szükséges mentési ablakot. 

Mentések tárolása. Mi az az időpont a 
múltban, ameddig vissza kell tudnunk nyúl 
ni? Hol helyezzük el a mentéseinket? 

Adathordozó-választás. Nagyon sok szem- 
pontot kell itt figyelembe venni, azonban 
figyeljünk oda, hogy olyan adathordozót vá- 


lasszunk, amire nemcsak ma, hanem a jövő- 
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ben is képesek leszünk elhelyezni a menten- 
dő adatmennyiséget: megfelelő a sebessége, 
a visszakereshetősége, a megbízhatósága, a tá- 
rolhatósága, az újrahasznosíthatósága és ter- 


mészetesen a fajlagos költsége. 


Mit mentünk? 
Alapvetően meg kell határoznunk, hogy a 


rendszerünkben mik azok az elemek, amelye- 
ket menteni szeretnénk. Ezek a dolgok alapve- 
tően két kategóriába sorolhatók. Az egyik ka- 
tegória az éppen zárt fájlok mentése. Ez az, ami 
különösebb gondot nem okoz, hiszen a menté- 


si folyamat kapcsán nem csinálunk mást, mint 


a fájlról készítünk egy másolatot. A második 
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A Volume Shadow Copy Service felépítése 











kategória a rendszer által használt adatbázisok 
és nyitott fájlok mentése. Ezt a feladatot nem 
tudjuk egyszerűen elvégezni. Az ilyen típusú 
adatok mentésére különböző technológiákkal 
és eszközökkel rendelkezünk. Ide sorolható a 
Volume Shadow Copy Service, a különböző 
mentési rendszerek speciális adatbázis agent 
jei, valamint a különböző export-import esz- 
közök, amelyek ismerik az adott alkalmazás 


vagy szolgáltatás tárolási módszereit. 


Az NTBackup 


A Windows beépített mentőeszköze az 
NTBackup. Ennek az eszköznek a lehetősé- 
geihez kétféleképpen férhetünk hozzá. Az 
egyik egy egyszerű grafikus felület, a másik 
egy parancssori felület. A továbbiakban első- 
sorban ez utóbbiról lesz szó. Először vizsgál 
juk meg, hogy milyen feladatokra is alkal 
mas ez az eszköz! 
m A kiválasztott fájlok és mappák mentése/ 
visszatöltése. 
an Másolat készítése a rendszerállapotról 
(System State). A rendszerállapot olyan 
adatokat tartalmaz, amelyek fájlszinten 
nem érhetők el, mert általában folyama- 
tosan nyitott adatbazisokbani tárolódnak: 
Ide tartozik például a registry. Ezeknek az 
adatoknak a mentéséről azért kell gondos- 
kodnunk, mert egy teljes rendszer-visszaál- 


lítás nem képzelhető el nélkülük. 
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a Automated System Recovery (ASR). Ez 
egy olyan technológia, amelyik teljes rend- 
szer-visszaállítás esetén gondoskodik az 
operációs rendszer minél gyorsabb megfe- 
lelő állapotba hozataláról: így válhat lehe- 
tővé az adatok visszatöltése. 

a Remote Storage és felcsatolt lemezek 
mentése. 

a Logfájl készítése a mentési műveletről. 

an Rendszerpartíció, bootpartíció,  vala- 
mint a rendszerindításhoz szükséges fáj- 
lok mentése. 

a Mentések időzítése. Az ütemezett felada- 
tok (Scheduled Tasks) segítségével képes a 
különböző mentési feladatokat időzíteni. 
Saját felülettel rendelkezik e feladatok ke- 
zelésére. 

a Médiakezelés. Cserélhető média esetén 
- mint amilyen például a szalag - képes a 
szükséges feladatokat (media pool kezelé- 
se, szalagformázás stb.) ellátni. 

an Online adatbázison alapuló Microsoft 
termékek adatainak mentése. Képes az 
összes olyan online adatbázis mentésére, 
amelyik kompatibilis a Volume Shadow 
Copy Servicesszel. 

Ezeken kívül azonban rengeteg olyan 
mentési feladat is van, amire az NI Backup 
nem alkalmas. Ilyen feladat például a nem 
Microsoft gyártmányú, VSS-szel nem kompa- 
tibilis online adatbázisok mentése. 

Vannak ugyanakkor olyan hiányosságai 


is az NIBackupnak, 


2. Backup Utility - [Untitled] 
Job Edit WView Tools Help 


(mlEdil x 


z Copy backup (másolat). Minden kijelölt 
fájlról másolatot készít, ugyanakkor nem 
jelöli mentettnek a fájlokat. 

a Daily Backup (napi mentés). A kijelölt fáj- 
lok közül azokról készít mentést, amik a 
mentés futtatásának napján módosultak. 
Nem jelöli mentettnek a fájlokat. 

a Differential Backup. Az utolsó normal 
vagy incremental típusú mentés óta módo- 
sult fájlokat menti. Nem jelöli mentettnek 
a tájlokat. 

a Incremental Backup. Az utolsó normal 
vagy incremental mentés óta módosult fáj- 
lokat menti. Mentettnek jelöli a fájlokat. 

a Normal Backup. Minden kijelölt fájlról 
másolatot készít. Mentett jelzéssel látja el a 
fájlokat. 


NTBackup parancssorból 

Mentéseink során három kérdést kell tisz- 
táznunk. Mit mentünk, hogyan mentünk és 
mikor mentünk? A továbbiakban bemutatott 
megoldások alapvetően merevlemezre törté- 
nő mentéshez készültek. 

Ha szalagos mentést választunk, akkor a 
bemutatott példákat, scripteket ki kell egé- 
szítenünk a szalagos adattároló kezeléséhez 
szükséges lehetőségekkel. Vizsgáljuk most 
meg a fent említett hármast! 

Mit mentünk? Azt, hogy mit mentünk, 
egy úgynevezett selection fájlban adhatjuk 


meg. Ez egy egyszerű szövegfájl, amelyik so- 


alol xi 





amelyeket kiegészíté- 
sekkel, ötletekkel or 


vosolni tudunk; ezek 


Ez Click to select the check box for any drive, folder or file that you want to back up. 
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hogy a sdájlok 


mit kell mentenie az 


(8 Removable Disk (E:) 
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A First Storage Group 








NITBackupnak, alap- 


vetően a fájlok két 


Backup destinatior 
File 
Backup media or file name: 


paramétere határozza 


For Help, press F1 


Az NTBackup grafikus felülete 


meg. Az egyik a fájl 
utolsó módosításának 
ielőpODtja "amasik az 
úgynevezett archive bit. Ez utóbbit minden, 
a fájl módosításával járó művelet köteles be- 
kapcsolni. Ezt a bitet törli a mentőalkalmazás 


mentésnél, amivel a fájlt mentettnek jelöli. 


Backup options: 
v Normal backup. Surnmary log. 
Some file types excluded. 


hő 


fD:xexchange301 004.bkf Browse... [ 





ronként tartalmazza a mentendő meghaj- 
tók, könyvtárak, fájlok elérési útvonalát. 
Lehetőségünk van arra is, hogy egy megadott 


nagyobb egységből kisebb szeletek mentését 
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tiltsuk. Ez utóbbit a sor végére tett /exclude 
kapcsolóval tudjuk megtenni. 


Példa egy egyszerű selection fájlra: 


CA 
c:vecycler /exclude 
da 
d:Necycler /exclude 


A fenti példa menti a rendszer C: és D: 
meghajtóját, kihagyva mind a két meghajtó- 
ról a lomtárat. A selection fájlnak kötelezően 
Unicode formátumúnak kell lennie, így akár 
egy egyszerű notepaddel is előállíthatjuk, 
azonban ennek hibátlan működéséhez szük- 
ségünk lesz a Windows Server 2003 SPl-re, 
ellenkező esetben trükközni kell az elmentett 
szövegfájl Unicode-fejlécével. 

Hogyan mentünk? A mentés különböző 
paramétereit parancssori kapcsolókkal tud- 
juk befolyásolni. A parancssor szintaxisát a 
legegyszerűbb, fájlba történő mentésen ke- 


resztül értelmezzük: 


ntbackup backup , Oselection fájl neve" /F , célfájl ne- 
ve" /L:5 /M normal 


backup - megadjuk, hogy a feladat, amit 
el akarunk végezni, az a mentés; 

,, dselection fájl neve? - annak a fájlnak 
a neve, amelyik meghatározza, hogy miket 
mentünk; 

/F , célfájl neve"? - annak a fájlnak a neve, 
ahová történik a mentés; 

/L:s - meghatározza, hogy mi kerüljön az 
NTBackup logjába. Ebben az esetben csak 
összefoglaló információt jelöl. 

/M normal - normál mentés (ez lehet még 
copy, incremental, differential vagy daily). 

Mikor mentsünk? Ezt a kérdést is meg- 
közelíthetjük több irányból. Az egyik lehe- 
tőségünk, hogy az előzőekben összeállított 
parancssort, egyszerűen a grafikus felületen 
keresztül felvesszük az ütemezett feladatok 
(Scheduled Tasks) közé, a másik, hogy a pa- 
rancssorból az schtasks parancsot paraméte- 


rezve tesszük ezt meg. 


Az NTBackup automatizálása 
Különböző scriptekkel akár még azt is meg 
tudjuk oldani, hogy a mentési művelet be- 


fejezéséről e-mailt kapjunk. Itt rögtön felme- 
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rülhet kérdésként, hogy mi is legyen ebben 

az e-mailben. 

Alapvető problémát okoz, hogy az 
NTBackup működéséről készült log egy igen 
eldugott helyen található a rendszerben, vala- 
mint az, hogy nem minden információ talál- 
ható meg benne, ugyanis sok, a működéshez 
kapcsolódó információ a rendszer esemény- 
naplójába kerül. Felmerül még elvárásként, 
hogy az NTBackup parancssorát kicsit egy- 
szerűbben lehessen kezelni. 

Az itt megfogalmazott elvárások teljesíté- 
sére készítettünk három olyan JScriptosz- 
tályt, amelyeket felhasználva kifejezetten egy- 
szerű scriptek készíthetők a mentési felada- 
tok megoldására. Ezek a scriptek példakó- 
dokkal együtt szabadon elérhetők a magyar 
TechNetoldalon. 

a Backup.js. Kezeli az NIBackup parancs- 
sori paramétereit, valamint összegyűjti a 
generált logjait. 

am Mail.js. Képes levelet küldeni a Collab- 
oration Data Objects segítségével. 

a EventLog.js. Begyűjti a saját működésé- 
nek idején keletkezett eseménynapló-be- 
jegyzéseket. 

Lássunk rögtön egy példát virtuális gépek 


mentésére ezek használatával! 


A Virtual Server 2005 R2 mentése 


Az informatikai infrastruktúrában egyre job- 
ban terjed a virtualizáció, azonban a vir 
tualizáció bevezetése magával hozza a mentés 
problematikáját is. 

Alapvetően kezelhetjük a virtuális gépeket 
úgy is, mint a fizikaiakat; ilyenkor a vendég- 
operációsrendszerben, az azon lévő eszközök 
kel oldhatjuk meg a mentést. 

A másik lehetőségünk, hogy a virtualizálás- 
ra szolgáló szoftver, esetünkben a Microsoft 
Virtual Server irányából közelítjük meg a fel- 
adatot. Ebben az esetben mindössze az egye- 
di virtuális gépeinkhez tartozó néhány fájlt 
kell mentenünk. 

Miután ezek a fájlok a vendég-operációs- 
rendszer mentése idején használatban van- 
nak, kézenfekvő megoldásnak tűnik egy 
Volume Shadow Copy Service alapú men- 
tés. Ezt sajnos ma még nem alkalmazhatjuk, 
mert a Virtual Server mai verziója (2005 R2) 
még nem támogatja a megoldást, azonban az 
SPI már orvosolja ezt a hiányosságot is. Az 
SP1 a cikk írásának pillanatában Beta 2 ki 


adásban érhető el. 
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A fentiek miatt a mentésre ma még más 
megoldást kell választanunk. Ez az egyedi vir- 
tuális gépeknél a következő lépésekből áll: 

a elmentjük a virtuális gépet (save state), 
vagy leállítjuk; 

a másolatot készítünk a virtuális gép által 
használt fájlokról; 

n visszaállítjuk az eredeti állapotot. 

Ezt a folyamatot elvégezhetjük kézzel, a 
grafikus felület használatával, vagy miután a 
Virtual Server rendelkezik megfelelő progra- 
mozói felülettel, akár scriptből automatizál 
hatjuk is. Az automatizációhoz készítettünk 
egy JScriptet (VSBackup.js), amelyik szintén 
illeszkedik a korábban ismertetett csomag- 
ba, és könnyebbé teszi számunkra az auto- 
matizációt. A script használatára álljon itt 


egy példa: 


C?xmIl version—" 1.0" encoding—"utf-8" ?— 
package xmlns—"http://schemas. microsoft.com/ 
WindowsScriptHost"— 
cjob: 
script language— JScript" src— "Mail. js75 
script language — JScript" src— " Eventlog.js" /5 
script language —"JScript" src— "VSBackup.js" /5 
script language — IScript" 5 
var mail — new Mail(); 
var el — new EventLog(ellogFileApplication -- 
ellogFileSystem -- 
elLogFileVirtvalServen; 
var vs — new VSBackup(); 
mail.MailServer — , mail.test.local": 
mail.From — , VSBackupcOtest.local"; 
mail.To — , administratorrOtest.local"; 
mail.Subject — , Test Backup"; 
vs.BackupPath — , cXbackuptt20060921.VS"; 
vs.BackupAll(); 
vs.ArtachLog(mail); 
el.AttachLog(mail); 
mail.Send(); 
a/script— 
2/iob: 
c/package— 


A mentés és visszaállítás témakörét en- 
nél részletesebben is bemutattuk nemrég egy 
TechNetwebcast alkalmával, ami mellett on- 
line elérhetőek az itt bemutatott scriptek 
és példák, valamint útmutatás található az 
SOL Server, az Exchange 2003, a DHCP és a 
RIS szolgáltatások mentéséről és visszaállítá- 
sáról is. Mindezek az információk elérhetők 
a http://www.microsoft.hu/technet/ntback- 
up linken. 

Gömöri Zoltán 


(sufOfreemail.hu) 
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ARCVONAL 


Védelem üzleti alapokon. 


z egyre üzletcentrikusabb fenyegetések miatt a szervezetek is mind gyakrabban ébred- 
nek rá, hogy a védelemnek is üzleti szemléletűnek kell lennie. A Microsoft 2006 jú- 
niusában bejelentett Forefront koncepciója olyan termékcsalád, amelyet kifejezetten 
az üzleti rendszerek védelmére szánnak. A , családtagok" könnyen integrálhatók egymással 
és a szervezet meglévő ILrendszerével, valamint kiegészíthetők és együtt is működnek más 
fejlesztők technológiáival. Az alábbi cikkben azt tekintjük át, mik is várhatóak pontosan a 
Microsofttól a következő egy évben a biztonsági szoftverek terén, és mik a mozgatórugói en- 


nek a kezdeményezésnek. 


A hálózat határainak védelme 
A Forefrontban a perembiztonság és a hozzáférés feletti ellenőrzés az ISA 2006 feladata. Az 

ISA integrált biztonsági átjáróként védi a belső környezetet az internet fenyegetéseitől, és a jo- 

gosult felhasználók számára lehetővé teszi a belső erőforrások gyors és biztonságos elérését. Az 

ISA szolgáltatásait a TechNet Magazin korábbi számaiban már bemutattuk. A Forefront filo- 

zófiájában az alábbi alapvető forgatókönyvek szerint használható az ISA: 

n hozzáférés biztosítása külső felhasználók számára a hálózat belső alkalmazásaihoz, alkalma- 
záspublikáció - Exchange, SharePoint, webes alkalmazásszerverek; 

an átjáróként, hogy a távoli munkahelyek hozzáférhessenek a központi hálózathoz; 

a biztonsági képességei révén alkalmas a külső vagy belülről induló fenyegetések elleni véde- 
lemre (itt érdemes megemlíteni, hogy az ISA 2006 már a forgalmi anomáliák alapján is fel 
tud ismerni egy elosztott szolgáltatásmegtagadási - DDOS - vagy féregtámadást, annak el 
lenére hogy protokoll szerint a forgalom teljesen szabályos, és nem tartalmaz káros kódot, 
de az adott protokoll vagy IP-cím által generált forgalom eltér a szokványostól). 

A család legújabb tagja, a Whale Communicationstől származó IAG (Internet Application 

Gateway) felel a SSL-VPN kapcsolatért, védi a webes alkalmazásokat, és a meglévő felügyelt 


és nem menedzselt végpontok kavalkádjában is gondoskodik a végpontbiztonságról. 


A szerveralkalmazások védelme 
A szervezetekben szükség van az üzlet szempontjából kritikus üzenő- és csoportmunka- 
rendszerek vírusok, férgek, kéretlen küldemények elleni védelmére. A Microsoft Fore- 
front Security for Exchange Server (FSES), Security for SharePoint és Security for Office 
Communications Server triásza védi azokat a kiszolgálókat, amelyeken az Exchange Server, 
a Windows alapú SMT P-átjárók, az Office Communications Server és a SharePointszolgál 
tatások működnek. 

Az együttes előnyök: 
n a több pásztázóeszköz több rétegben ellenőrzi a kommunikációs struktúra biztonságát; 
un a szoros integráció a Microsoftszerverekkel fokozza a hozzáférhetőség és a felügyelet haté- 


konyságát; 


VAA 





a a tartalomeellenőrzés miatt a külső és bel 
ső kommunikációban is kiküszöbölhetők 

a helytelen tartalmak és a veszélyes külde- 

mények. 

Az egyedi Forefront védelmi megoldások 
önmagukban is hatékonyak, de ha a réteges 
védelem miatt valamelyik szinten mégis át 
csúszna egy támadás, akkor egy további réteg- 
ben jó eséllyel blokkolódik. 

A Forefront védelmében nem kevesebb, 
mint kilenc(!) kártevőellenes motort lehet 


használni: Microsoft (Sybari), CA Inoculate- 


A Forefront termékvonal elemei 





Az egységes rendszer a következő megoldásokból 
áll össze (zárójelben az adott technológia korábban 
érvényes elnevezése): 

Internet Security and Acceleration (ISA) Server 
2006; 

Forefront Security for Exchange Server (Antigen 
for Exchange); 


Forefront Security for SharePoint (Antigen for 
SharePoint); 

Forefront Security for. Office. Communications 
Server (Antigen for Instant Messaging); 

Forefront Client Security (Microsoft Client Protec- 
fion). 





II, CA Vet, Norman, Sophos, Authentium, 
Kaspersky, a magyar VirusBuster és AhnLab. 
Mindegyik technológiának megvan az erős- 
sége, és a Forefront védelme úgy épül fel, 
hogy erősítik egymást. A motorokat termé- 
szetesen együtt is lehet használni, de ötnél 
többet nem célszerű kombinálni a védelem 


és teljesítmény egyensúlya miatt. 
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Az FSES a vírus- és féregszűrésen túl mind 
a csatolt állomány típusa, mind annak tar- 
talma alapján képes elemezni, és a megfelelő 
házirend szerint engedélyezni, törölni vagy 
karanténba zárni a beérkező üzeneteket. 

Csatolt állomány szűrési lehetőségei. Va- 
lós állománytípus alapú szűrés (a csatolt 
állomány bináris fejléce egyértelműen meg- 
határozza annak típusát, kiterjesztéstől füg- 
getlenül: 

a állománykiterjesztés alapú szűrés; 
a állománynév alapú szűrés; 
a állományméret alapú szűrés. 

Kulcsszó alapú tartalomszűrés. A szűrés 
történhet sima szöveg vagy HTML szöveges 
üzenet törzsében, a fejlécben vagy a tárgy- 
mező adata alapján. Ha mind a sima, mind 
a HTML szöveg tartalmazza a keresett kulcs- 
szót, két különböző riportbejegyzés történik. 
Megadható, hogy hány kulcsszóegyezés ese- 
tén hajtódjon végre a megadott akció (karan- 


tén vagy törlés). 


Kétszintű levélszemétszűrő rendszer 
Alapvetően két nagy csoportra oszthatjuk 
a levélszemétszűrő technológiákat. A minta 
alapú rendszerek adott (már ismert) levelet, 
annak egy részét vagy szófordulatot keres- 
nek. Ezt a , levélszemétgyártók" különböző 
technológiákkal próbálják megkerülni (a tel 
jesség igénye nélkül lássunk kettőt): 

Hash busting. A hash alapú szűrők kiját 
szását célozza. A hash-minta alapú szűrők az 
interneten felálított érzékelőkön áthaladó 
üzenetekről egy hash-t (ujjlenyomatot) vesz- 
nek és ezt hasonlítják össze a postafiókba ér 
kező üzenettel. A hash-képzés matematikájá- 
nak köszönhetően az eredeti üzenet tartalma 
nem fejthető vissza (így személyiségi jogokat 
nem sért), de egyben ez a gyenge oldala is. Az 
eredeti üzenet néhány karakterrel vagy egy 
néhány pixeles képpel kiegészítve már másik 
hash-t ad. A spammerek pont ezt használják 
ki, és több ezer (néhány karakter vagy pixel 
megváltoztatásával) verziót küldenek szét. 

Snowftlaking (hópihe-módszer). Akárcsak 
a hópehely, minden üzenet lehet egyedi, né- 
hány apró rész megváltoztatásával vagy hozzá- 
adásával. A hash bustinghoz hasonlóan itt is 
az a cél, hogy a minta alapú szűrőn ne akad- 
jon fenn a levél. Fontos tudni, hogy minden 
spamszűrő pontozza az üzeneteket. Vannak 
olyan elemek, amelyek egyértelműen spam- 


mé, míg mások egyértelműen nem spammé 
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minősítik a levelet. Sok esetben a nem spam 
mindősítés felülírja a spam jelölést, hiszen 
,inkább csorogjon be egy spam, mint hogy 
kitöröljünk egy fontos üzenetet". Ezt hasz- 
nálja ki a snowflaking, amely HTML üzene- 
tek esetében rejtett, láthatatlan, fehér szöve- 
get helyez el a sorok között. Mivel a spamszű- 
rők sok esetben gyanúsan kezelik a fehér ala- 
pon fehér szöveget, a spammelők sok esetben 
a 65535 színkombináció közül a fehér -l ... 
8 árnyalatot választják. A láthatatlan szöveg 
pedig üzleti szöveg (például: Hivatkozva a 
legutóbbi megbeszélésre stb...), aminek ha- 
tására a spamszűrő ,nem spam" mindősítést 
ad a levélnek, annak ellenére, hogy a levél 
törzs többi része lehet, hogy Viagra vásárlá- 
sára buzdít. 

Vannak olyan spamszűrők, amelyek az e- 
mail feladója alapján döntik el, hogy kéret 
len-e az adott levél. Nincs azonban jelenleg 


garancia arra nézve, hogy a levél valóban at 


Microsoft" 


Frore 


tól származik, aki feladóként fel van benne 





tüntetve. Egyre inkább terjed a , spoofing", 
vagyis az e-mail feladójának meghamisítása, 
mert a kéretlen levelek feladói viszonylag 
egyszerűen kijátszhatják a szűrőket. Ennek 
kivédésére született meg a üzenetet feladó 
tartomány ellenőrzése - lényegében úgy, aho- 
gyan a telefonok hívóazonosítójának köszön- 
hetően megjelenik a hívó fél telefonszáma. 

a Az e-mailt küldő kisebb vagy nagyobb 
szervezetek közzéteszik kimenő e-mailki- 
szolgálóik IP-címét a DNS (tartománynév) 
rendszerben, az ,e-mailküldőazonosító" 
specifikációjában előírt formátumban. 

a A fogadó e-mailrendszerek minden üze- 
netet megvizsgálnak, hogy megállapítsák, 
milyen tartományból valónak állítja ma- 
gát az üzenet (azaz, hogy milyen internetes 
tartomány van feltüntetve az üzenetben 
feladóként). 

a A fogadó e-mailrendszerek lekérdezik a 
DNS-ből az állítólagos feladótartomány 
kimenő e-mailkiszolgálóinak IP-címeit. 
Ezután ellenőrzik, hogy szerepeltee a listán 


az az IPcím, amelyről a levél érkezett. Ha 
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nem, akkor az üzenetet nagy valószínűség- 

gel hamis címről adták fel. 

A másik nagy csoportot a heurisztikus 
szűrőt tartalmazó megoldások alkotják, ahol 
szabályok és algoritmusok, egyfajta , mester- 
séges intelligencia" használatával próbálják 
eldönteni, hogy a vizsgált üzenet levélszemét 
vagy sem. Mint minden szabályon alapuló 
hipotézisre, erre is igaz az a mondás, hogy 
, Kivétel erősíti a szabályt! ". 

A heurisztikus szűrők a folyamatosan vál 
tozó levélszemétáradattal csak részben ké- 
pesek megbirkózni, hiszen ahogy az emberi 
viselkedés sem írható le teljes egészében sza- 
bályokkal, a változó levélszemét sem (amit, 
ugye, emberek gyártanak). 

Érdemes még egy kérdést megvizsgálni! 
Hogy kerülünk fel a spammerek küldőlistá- 
jára? Míg korábban a levélszemetelők vala- 
mennyi lehetséges címre (válogatás nélkül) 


elküldték ,ajánlatukat, addig manapság 


ront 


már sokkal célzottabban küldik azokat, kife- 


jezetten az általuk kiszemelt célcsoportnak. 





Ez az egyik oka annak, hogy a minta alapú 
(hash-ujjlenyomat) rendszereknél használt 
internetes csapdák csak a spamek egy részé- 
nek kiszűrésére alkalmasak. Jogosan merül 
het fel a kérdés, honnan veszik a spammerek 
a címeket? Lássunk néhány példát: 

Doménpróbálgatás. A kéretlen levél kül 
dője kiválaszt egy adott domaint (például 
contoso.com), majd ismert nevekkel párosít 
ja (például: kiss.gyula, k.gyula, kgyula, gyu- 
la.kissXcontoso.com). Minden olyan levél, 
ami nem jön vissza , címzett ismeretlen" hi 
baüzenettel, potenciálisan valós cím. 

Továbbá ha valaki bekapcsolja a , házon 
kívül" szolgáltatást külső címre, a spamgyá- 
ros még megerősítést is kap hogy ki a cím 
gazdája. Sok felhasználó ugyanis büszkén so- 
rolja valamennyi elérhetőségét aláírásában, 
amit odailleszt még az automatikus , házon 
kívül" válaszok végére is. 

Intelligens keresőmotorok. Sajnos a ke- 
resőmotorok hatékonyságát sokan rosszra 


használják, és a téma ráadásul tetemes szak- 


ya 
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irodalommal is rendelkezik (Google hack 
ing). Az ismert keresőmotorok jól paraméte- 
rezhetők, és nagy pontossággal keresnek ki 
valós e-mailcímeket fórumokból, nyilvános 
adatbázisokból, cégek weboldalairól, sajtó- 
anyagokból vagy éppen konferenciák webes 
tájékoztatóiból. 

A folyamatos rabló-pandúr harcban a le- 
vélszemétgyártók újabb és újabb eszközöket 
vetnek be, de a védelmi technológiák gyor- 
sabb ütemben fejlődnek, és ami még ennél 
is fontosabb, hatékonyságuk sokkal jobb, 
mint korábban, így a tévesen levélszemétnek 
minősített (falsh positive) levelek száma - a 
minta és heurisztikus szűrési technológiák 
kombinált használatával - 1 százalék környé- 
kére csökkenthető. Sokan azt mondhatnák: 
ez már egész jó érték, azonban nem szabad el 
felejteni, hogy a elektronikus levelek és ezen 
belül a levélszemét mértéke exponenciális ér- 
tékben növekszik évről évre. Egymillió üze- 
netet feltételezve már az 1 százalék is soknak 
mondható. Mint minden biztonsági meg- 


oldásra, erre is igaz, hogy réteges védelemre 


Az Intelligent Message Filter működése 





EE SZ ESZT EB 





Az FSES és az IMF közös SCL taget használ 


van szükség: , Egy zár - nem zár", azonban a 
két technológia egyidejű alkalmazása jó ha- 
tásfokkal szűri ki a növekvő ütemben érkező 
kéretlen levelek hadát. 

Az FSES egy minta alapú levélszemétszűrő 
motorral egészíti ki az Exchange 2003-ban 
már megismert, heurisztikus elven működő 
IME (Intelligent Message Filter) szűrőt. 

Az FSES motorja három alapvető funkciót 
tartalmaz: 


a a Bullet SignatureDatabase-t, amely lehe- 





Amikor egy külső felhasználó e-mailt küld egy olyan Exchange-kiszolgálónak, amelyre telepítve van az Intelligent Mes- 
sage Filter, az Intelligent Message Filter megvizsgálja az üzenetek szövegét, és egy SCL-pontszámot rendel az üzenethez, 
amely azt jelzi, hogy az zenet milyen valószínűséggel kéretlen levél. Ezt a pontszámot az üzenet egy tulajdonságában 


tárolja, amelynek spam-valószínűségi szint (spam confidence level, SCL) a neve. A pontszám tartósan része marad az 
üzenetnek, még akkor is, ha más Exchange-kiszolgálókra továbbítja őket a rendszer. 
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Intelligent 
Message 


A rendszergazda két küszöbértéket állíthat be arra vonatkozóan, hogy hogyan kezelje az Intelligent Message Filter a 
különböző SCL-pontszámot tartalmazó leveleket: egy átjáró-küszöbértéket, amelyhez egy, a küszöbértéket meghaladó 
üzenetekre vonatkozó művelet társítható, valamint egy postafióktár-küszöbértéket. Az átjáró küszöbértékénél nagyobb 
pontszámú üzenetek esetén az Intelligent Message Filter végrehajtja az előírt műveletet (például a törlést). Ha az üze- 
net pontszáma kisebb az átjárón érvényes küszöbértéknél, a kiszolgáló továbbítja az üzenetet a címzett postaládáját 


tároló Exchange-kiszolgálónak. Ha az üzenet pontszáma nagyobb az Exchange Server postafiók-tárolójára vonatkozóan 
megadott küszöbértéknél, a postafiók-tároló nem a felhasználó Beérkezett üzenetek mappájába, hanem a Levélszemét 


mappába kézbesíti az üzenetet. 





ye 


Junk 
E-mail 








töővé teszi a spamküldők és leveleik felis- 

merését, illetve a Spammer Irick Analysis 

and Response rendszert, amelyik felismeri 

a sbpamküldők módszereit és trükkjeit; 

a a SpamCure motor kilenc üzenet, fejléc 
és forgalomelemzési kategóriát tartalmaz 

a DNS-iinformáció, a tárgymező, az [IP 

cím, a küldő és a levéltörzs-információk 

alapján, a motort úgy alakították ki, hogy 
adatbázisát napi több alkalommal tartják 
karban és frissítik; 

a IME-ESES együttműködés: az FSES és az 

IMF közös SCL taget használ. 

Az ESES három különböző üzenetmegje- 
lölési (tag) módszert alkalmaz. 

Tárgy-tag. Adott szöveggel (például , levél 
szemét") egészíthető ki a levél tárgysora, ami 
alapján - ha erre van szükség - kliensolda- 
li szabály használatával lehet a ,junk mail" 
mappába irányítani a levelet. 

Üzenetfejléc-tag. Hasonló módon a tárgy- 
sori jelöléssel, itt az üzenet fejlécsora módo- 
sítható. 

SCL-felülírás. Az IMF által megadott 
spam-valószínűségi mutató felülírása (csak § 


SCL -szintemelés lehetséges). 


Kliens- és platformvédelem 
A Forefront Client Security a Windows ala- 
pú kliens- és szerveroperációsrendszereket 
használó számítógépeket védi. Ugyanolyan 
hatékony a ,jó öreg" vírusok, férgek és tró- 
jaiak elleni védelemben, mint a , modern" 
kémprogramok és a bujkáló rootkitek ellen. 
Természetesen ez is integrálható a meglé- 
vő infrastruktúrához - például az Active 
Directoryhoz - és a többi biztonsági megol 
dáshoz. A Client Security nyilvános próba- 

változata 2006 vége felé várható. 
Kelemen László 
kelemencoOhungary.com 


Microsoft TechNet 
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MESSZE VAGYUNK 
MÉG? MESSZE... 


Legutóbbi cikkünkben a párhuzamosság alapvető kérdéseivel 


toglalkoztunk, most pedig megnézzük, hogyan lehet 


a szerverszoftverek skálázhatóságát alapul véve megoldást találni 


a kliensszoftverek teljesítményének javítására. 


elenleg azok a legjobban skálázható szoftverek, amelyek felhasználók és lekérések ezreit 
szolgálják ki - látszólag teljesen egyszerre. Az ok egyszerű: eddig igazán csak ezeknél volt 
kérdéses a skálázhatóság, itt foglalkoztak a témával a kellő alapossággal. 

Ilyen, már most is skálázhatóságra tervezett szoftverek például a web- és alkalmazásszerve- 
rek (például az I[IS), valamint az SOL Server, és ide tartoznak olyan keretrendszerszintű meg- 
oldások is, mint például a . Net CLR thread poolja, végül pedig a tudományos számítások 
elvégzésére is alkalmas fürtözött HPC- (High-Performance Computing) rendszerek, mint pél- 
dául a Windows Server 2003 Compute Cluster Edition. De mitől is olyan skálázhatóak ezek, 


és miben különböznek egymástól? 


Melyek a skálázhatóságot befolyásoló tényezők? 
A szerverszofítverek általában lekérdezések kiszolgálására vannak optimalizálva. A lekérdezé- 
sekkel szemben a következő általános igények fogalmazódnak meg: 


a Mennyi az egyszerre fel 


NLB Firew all Cluster web Server NLB Cluster 


dolgozandó lekérdezések 
száma? 

a Mekkora a lekérdezések 
elvárt válaszideje? 

a Mekkora a lekérdezések 


átlagos feldolgozásigénye, 


NLB host 4 
ISA2000 Server NLB NLB 
9 host - IIS host - IIS 







" To data 
storage 


mennyire terheli le egy 


NLB host -k 


ilyen lekérdezés a rendszer SÉRZTGT e erett 


NLB 
host 4 IIS 


NMLB 
host 4 IIS 


egészét (milyen komplex 

egy áltagos lekérdezés)? IIS webszerver-farm terhelésmegosztással és ISA Serverrel 

a Mekkora adatmennyiség- 
re van szükség a feldolgozás során (közös erőforrásokról olvasva, illetve a lekérdezés saját 
paramétereit tekintve)? 

an Mennyire kell friss, aktuális adatokkal számolni a feldolgozás során (mennyire használha- 
tunk cache-elést, mennyire tudjuk kihasználni a lokalitás elvét)? 

an Mennyire függnek egymástól időbeli egymásutániság vagy adatfüggőségek miatt az egyes le- 


kérdezések, vagyis mennyire párhuzamosíthatók (lockolás, időbeli szinkronizáció)? 


VOLNEK NAG E aa 


a Milyen közös erőforrásokat használnak a 
függő vagy független lekérdezések (sávszé- 
lességigények, adatdependenciák)? 

a Történik-e írási művelet közösen használt 
erőforrásokba, és az befolyásolja-e a soron 
következő, adott sessionön belüli lekérde- 
zések működését (stateful vagy stateless)? 

a Ha történik írási művelet a közös erőforrá- 
sokba, milyen ACID izolációs szintre van 
szükségünk? 

Nem fogunk minden egyes kérdést rész- 
letesen vizsgálni, hiszen hatalmas mennyi- 
ségű, tapasztalati úton és kutatással szerzett 
információ áll mögöttük. Ami igazán fontos 
minden esetben, hogy az egyes szerveralkal 
mazás tervezésekor vagy egy arra épülő meg- 
oldás készítésekor pontosan el tudjuk dön- 
teni, milyen teljesítményigényeink vannak, 
és tudnunk kell, milyen lehetőségeink áll 
nak rendelkezésre az optimalizációhoz. Ezek 
után nekünk kell megtalálnunk az egyen- 
súlyt az egyes igények és a lehetőségek kö- 


zött, és ez egyáltalán nem egyszerű feladat. 


A webszerver 

és az adatbázisszerver esete 

Nézzünk pár példát! A webszerverek az ese- 
tek többségében egy közös lemezalrendszer- 
ről dolgoznak (vagyis a közös erőforrás jelen 
esetben a lemezen található HTML- vagy di- 


namikus webes állományok), a lekérdezése- 
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ket azonban párhuzamosan több szerverszá- 
mítógép és azon belül több processzor is ki- 
szolgálhatja. Jellemzőek rájuk az aszinkron, 
stateless lekérdezések, legalábbis ha csak 
adott weboldal lekérdezéséről van szó, amit 
a kliens meg szeretne jeleníteni, mondjuk 
egy böngészőben. Ezeknél a lekérdezéseknél 
a cache-elés is erőteljesen használható, és az 
nem csak a szerver, de a kliens oldalán is erő- 
sen megjelenik (képek, statikus weblapok lo- 
kális cache-elése). 

Ha szükségünk van arra is, hogy adatokat 
módosítsunk egy webes lekérdezés következ- 
tében (mondjuk egy online bolt esetében, 
amikor a felhasználó rendel valamit, és meg- 


adja adatait, valamint lefoglal az árukészlet 


webszerverek esetében egy adott lekérdezés 
gyorsítására több processzormag felhasználá- 
sával; ugyanakkor viszont képesek vagyunk 
egy időben akár több ezer lekérdezés kiszol 
gálására is úgy, hogy a lekérdezéseken a szer 
verek és a processzorok valóban párhuzamo- 
san dolgoznak. 

Az SOL Server esetében jellemzően pro- 
cesszoronként egy-két szál fut csak, amelyek 
mind egy adott lekérdezést szolgálnak ki. Az 
SOL Server célja, hogy egy adott lekérdezést 
mielőbb végre tudjon hajtani, ugyanis egy 
adott lekérdezés vagy tranzakció állapotának 
kezeléséhez igencsak sok memóriára lehet 
szükség, és egyáltalán nem kedvező, ha ezt 


a memóriaterületet szálváltogatásokkor kell 


A lokalíitás elve 





A lokalitás lényege, hogy a számítógépekben és nagyobb, elosztott rendszerek esetében is az a lehető leghatékonyabb, 
ha a feldolgozandó, illetve az adott feladat elvégzéséhez szükséges adatok a lehető legközelebb vannak a feldolgozó 
egységhez, vagyis a processzormaghoz. 

Minél közelebb van az adat, annál gyorsabban éri el azt a processzormag, illetve gyorsabban juttatható el a procesz- 
szormag közvetlen közelébe. A leggyorsabbak a regiszterek, majd az adott mag vagy a processzor közös használatú 
L1—L2—L3 cache-e, utána sorban következhet a szál saját lefoglalt memóriaterülete, a más szálak által lefoglalt és kö- 
zös memóriaterületek, majd a virtuális, illetve kiswappelt memória, és végül maga a merevlemez. Ha többgépes rend- 
szereket vizsgálunk, akkor még a hálózati sebesség és távolság függvényében a távoli rendszereken található adatok is 
szóba kerülhetnek, vagy éppen a hálózaton vagy üvegkábelen keresztül bekötött közös tárolóeszközök is. 

Alapvető cél, hogy minden adatot, amire szükségünk van, a feldolgozáshoz a lehető legközelebb tároljuk (és olyan for- 
mában, ami a feldolgozást minél rövidebbé teszi, transzformációs lépéseket is feltételezve az adatmozgatáson túl). 
Ezenkívül arra is fel kell készülnünk, hogy frissítsük is ezeket a lokális adatokat, ha szükséges (mivel az eredeti adat már 
megváltozhat, miközben a gyorsabb memóriaterületen már nem aktuális adatokat tárolunk a feldolgozás számára). En- 
nek optimális megoldása nem egyszerű feladat, és általában leegyszerűsítve egységesen a , cache-elés" névvel illetjük. 
Ennek a cache-elésnek hardveres és szoftveres megoldásai is vannak. A szoftveres megoldások többségével a fejlesz- 
tőknek folyamatosan foglalkozniuk kell, de felügyelt kódban a Garbage Collector és más háttérszolgáltatásoknak hála 
lényegesen kevesebbet, mint natív kód esetében. De még felügyelt kódban is oda kell figyelni a lokalitásra, ha a skáláz- 
hatóság és a teljesítmény további növelése a cél — mindig meg kell találni ugyanis a számunkra megfelelő egyensúlyt az 
adatok frissessége, konzisztenciája, az egyszerre fogadható szálak száma és az egyes szálak teljesítménye között. 





ből), akkor azt ideálisan egy háttéradatbázis 
segítségével tehetjük meg, ami már a web- 
szervertől eltérő módon skálázható. Emellett 
persze használhatjuk akár a webszerver saját 
(stateful) session-kezelését is, ez azonban is- 
mét teljesen más esetet eredményez, hiszen 
több a közösen használt erőforrás, nagyobb 
a lekérdezés memóriaigénye, és ilyen esetek- 
ben nagyon oda kell figyelni, hogy egy ses- 
sion minden egyes lekérdezése ugyanarra a 
szerverre érkezzen be - ebben az ISA Server 
tud például segíteni. 

Mi az, ami itt végül is párhuzamosítható 


volt? Láthatóan nincs igazán jó megoldás 


Va 


felcsorgatni a felsőbb cache-ekbe, vagy ha 
egyszerűen megtelik a fizikai memória. Az 
SOL Server - mint ahogy a legtöbb adatbázis 
is - alapvetően stateful működésre van felké- 
szítve, de azon belül szinte minden kontroll 
a fejlesztő kezében van: a tranzakciók keze- 
lése révén, a számunkra szükséges izolációs 
szint kiválasztásával mi magunk dönthetjük 
el, hogy a teljesítmény vagy az ACID elvek 
szigorú betartása a fontosabb számunkra. 

Az adatbázisszerverek kivételesen jól tud- 
nak scale up irányban nőni, akár egészen 
64 processzorig is. A Microsoft SOL Server 


azonban jelenleg csak akkor képes igazán 


EE 


scale out irányban nőni, ha az alatta lévő 
adatok lehetővé teszik (például az adatok 
adott szisztéma szerint particionáltak egy 
fürt szervereire, ami módot ad több felhasz- 
náló más adatbázis-partícióból történő egy- 
idejű kiszolgálására). 

Az SOL Server egy adott lekérdezést is ké- 
pes több processzormag között megosztani, 
ha az számításai szerint valóban gyorsabbá 
teszi a feldolgozást; de az sem okoz problé- 
mát, ha több, különböző lekérdezést kell pár 


huzamosan futtatnia az egyes magokon. 


NT T TT án total X 





Chris Brumme hosting blogja: 
http://blogs.msdn.com/cbrumme 
Nicholas Blachford érdekes cikkei a témában: 


http://www.blachford. info /computer/articles/ 
bigcrunchl.htmi 





Összefoglalva: a webszerverek esetében ál 
talában kisebb és egyszerűbb az elvégzendő 
feladat, kevesebb a közös erőforrás, ami le- 
hetővé teszi a szerverek kényelmes scale out 
és némileg limitált scale up skálázását is. 
Azonban nem tud egy adott lekérdezésen 
gyorsítani, hiába áll több processzormag ren- 
delkezésre, csak a lekérdezések együttes ki- 
szolgálásával ér el teljesítménynövekedést. 
Az SOL Server ezzel szemben sokkal komple- 
xebb feladatok ellátására is képes, de minden 
erőforrás gyakorlatilag közös (hacsak nem 
tudjuk teljesen elszigetelten particionálni az 
adatokat) és képes akár egyetlen lekérdezést 


is párhuzamosítani, de csak ha van értelme. 


Új utakon 


Mint láttuk, van már néhány (bár egymástól 
nagyban eltérő) lehetőségünk arra, hogy egy 
többfelhasználós, többszálas rendszert haté- 
konyan megépítsünk. Viszont felmerül egy 
másik kérdés: hogyan gyorsíthatók párhuza- 
mosítással az alapvető programozási algorit 
musok, amelyek nem SOL-ben vannak, és 
mondjuk nem is weboldalról beszélünk? 
Hogyan gyorsíthatók azok a kódok, amelye- 
ket a ma elterjedt programozási nyelvekkel, 
mondjuk .Net keretrendszerre készítünk el? 
Hogyan tudjuk kihasználni a párhuzamossá- 
got anélkül, hogy explicit módon törődnénk 
a szálkezeléssel, és mindent külön szálakra 


akarnánk szétdobálni? És talán a legfon- 


Microsoft TechNet 





tosabb: hogyan tudjuk mindezt nemcsak a 
szerverszoftverekkel, hanem akár a kliensalb 
kalmazások esetében is megvalósítani? 

A kliensalkalmazások rendkívül kényesek: 
az operációs rendszer szempontjából szinte 
minden egyes futó szoftver stateful , lekér- 
dezésekből", vagyis ez esetben parancsokból 
áll, amelyek többnyire izolált szálakba és fo- 
lyamatokba vannak szervezve. A kliensszoft 
ver által kiadott parancsok szinte soha nem 
párhuzamosíthatók, hacsak a fejlesztő nem 
szervezi őket külön szálakba, vagy nem indít 
ja el aszinkron módon, ami ilyenkor egy, a 
Thread Pool által létrehozott worker thread- 
en kezd hozzá a feladat végrehajtásához. 

Nyúljunk vissza az SOL-hez - elvégre az 
adatbázisszerverek készítői tudják talán a 
legjobban, hogyan is lehet növelni egy le- 
kérdezés sebességét, és az SOL Server skáláz- 
hatósággal kapcsolatos igényei vannak talán 
a legközelebb a kliensalkalmazáséhoz, leg- 
alábbis ha egy adott parancs vagy lekérdezés 
gyorsítása a cél. 

Annak több oka is van, hogy az SOL sok 
szempontból kiemelkedő teljesítményt tud 
elérni. Bár nem tértünk ki rá, de belső szál 
és memóriakezelése optimálisra sikerült a 
lekérdezések szempontjából; viszont ami iga- 
zán fontos, hogy nekünk, programozóknak 
szinte csak azt kell megmondanunk, hogy 


mit szeretnénk a lekérdezés eredményeként 


Update Customer 25047 
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kapni, és nem azt, hogy hogyan. 

Ez azzal jár, hogy a rendszer motorja képes 
helyettünk hatékony és akár párhuzamos kó- 
dot is készíteni, és nemcsak a kapott adato- 
kat, hanem a lekérdezés optimalizált tervét 
is cache-eli nekünk, anélkül, hogy ebből bár- 
mit is látnánk, így legközelebb mindez még 


gyorsabban történik. 


Accessing data with DLInd 


b 
1 


public class Customer ( ...) 


public class Northwind: DataContext ; 


ú 


public TablecCustomer? Customers; 


Classes 
describe data 


A 
vi 


a í TR 
ML EAISZE e 
collections 


köze 


Ket 


Strongly typec 
connection 


Northwind db — new Northwindk. .. § E 


var contacts — 
from c in db. Customers 
where c.City —— "London" 


erez em 
Tt 


ezt 


[TT 


integrated 
guery syntax 


select new ( c.Name, c.Phonek 


Adatelérés LINO-kel 


Lássunk néhány érdekes újdonságot, ame- 
lyek az előbb részletezett előnyöket próbálják 
meg kihasználni a kliensoldal, illetve a nem 


multituser szoftverek gyorsítására! 


r LING — DOTMUZ 


. A LINO (Language Integrated Ouery) tech- 


nológia a soron következő 
ADO.NET tészeként jelent 
kezik, és a Ct 3.0, valamint 
az új Visual Basic nyelv szer- 
ves részévé válik majd. A 
PLIN (Parallel LINC) en- 
nek egy speciális alfaja, ami 
kifejezetten a párhuzamosság 
kihasználását tűzte ki céljául. 
Anélkül, hogy elmélyednénk 


a részletekben, lássuk, miért 





Customers 
30001-40000 


is érdekes ez. 

A LING dióhéjban arra va- 
ló, hogy különféle ciklusok 
kialakítása és parancsok egy- 
más után rakosgatása helyett lehetőségünk 
legyen arra, hogy a hagyományos programo- 
zási nyelvekkel tetszőleges adatvektorokat, 
illetve listákat SOL-szerű szintaktikával dol 
gozzunk fel. Így a rendszer lehetőséget kap 
arra, hogy kitalálja helyettünk, hogyan lesz a 
leghatékonyabb az adott lekérdezés lefuttatá- 


sa, akár több processzormag felhasználásával 





is (és persze az sem mellékes, hogy a meg- 
írandó kód is messze egyszerűbb, áttekinthe- 
tőbb, célorientáltabb lesz ezáltal). A lényeg: 
nem szabad szekvenciálisan gondolkodni. 
Azt mondjuk meg, mit szeretnénk, a többit 
bízzuk nálunk okosabbra! 

A PLINO hatékonyságát matematikailag 
is bizonyították, amit jól szemléltet a követ 
kező, bár kevéssé tudományos megállapítás- 
sorozat is: minden LINO-lekérdezésnek van 
SOL-megfelelője. Minden SOL-lekérdezés re- 
lációs algebrára fordítható, és minden relá- 
ciós algebrával leírt egyenlet párhuzamosít 
ható. Ezt az egészet az is segít alátámasztani, 
hogy az adatbázisszerverek motorjának fejlő- 
dése az elmúlt 20 évben jelentős mértékben 
fókuszált az SOL-lekérdezések párhuzamos 
feldolgozására, nem kevés sikerrel - most 
csak ezt a már meglévő tudást hasznosítjuk 
újra, más környezetekben. Hamarosan meg- 
érkeznek az első publikus teszteredmények is 
a PLINO-ről - az viszont már most elmond- 
ható, hogy amiket most házon belül látni le- 
het, nagyon meggyőzőek! 

A LINE arra is képes, hogy ugyanezek: 
kel a nyelvi eszközökkel egy tényleges adat 
bázison futtassuk le a lekérdezéseinket. Ez 
azt jelenti, hogy nem kell többé stringekben 
írogatnunk SOL-parancsokat (csak ha sze- 
retnénk), vagyis végre minden teljesen tí- 


pusosan kerül feldolgozásra, így jelentősen 
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csökken a szükséges kód mennyisége, és nem 
kell az adatkezelési réteggel annyit foglalkoz- 


nunk, mint korábban. 


Tranzakciókezelés a memóriában? 

A szofítverfejlesztés egy alapvető dolgot gyak- 
ran figyelmen kívül hagy (a legnagyobb üzle- 
ti rendszerek kivételével): az adatok a kom- 
munikáció során mindig korábbi állapotot 
tükröznek, vagyis potenciálisan már elavul 
tak (hacsak nem lockoljuk az adott memória- 
darabot az adott gépen, de akkor meg nem 
beszélhetünk nagyon skálázhatóságról). Az 
esetek többségében azonban nem is célunk 
az éppen abban a nanoszekundumban aktuá- 
lis adattal dolgozni, csak szeretnénk kapni 
egy olyan állapotot, ami konzisztens, és lehe- 
tővé teszi számunkra a hibátlan műveletvég- 
zést, reagálást. 


Gyakorlatilag ez a lényege az ACID-elven 


Szál- és processzormag-affinitás 


Általánosan érvényes tény, hogy egy adott, többszá- 
lú kód akkor tud a leggyorsabban futni, ha minden 





egyes hardveres szálon (hardveres szál: processzor- 
mag vagy HyperThreading esetén logikai processzor) 
egy időben egyetlen szál fut, egészen addig, míg a 
szál a feldolgozás végére nem ér. Ha több szál fut 
egy processzormagon, akkor azok valójában nem is 
futnak egyszerre, hanem csak felváltva, és a szál- 
váltásokkor a szálak által használt memóriának, 
illetve a stacknek be kell kerülnie a processzorhoz kö- 
zeli memóriatárakba, például a lehető legközelebbi 
cache-szintre. Ha gyakran váltogatjuk, hogy melyik 
szoftveres szál fut az adott hardveres szálon (ilyen 
például a hagyományos preemptív multitasking is 
egy processzoron), akkor a hardveres szál cache-ét 








All locks derive from a (simple!) common class 


public abstract class System.Threading.LockBase 


/"" Methods 

public Jiszrigrb void EnterŐ 

public abstract void ExitO; 

DUDTAK virtual bool TryEnter(rimespan timec szid) 

public abstract bool tiz áét ig millisecondsTimeout); 


8 Properties ta / 
public string Name k get; ) 

public bool] IsHeld ket Hi 

public boo] IsReentrant hi 

public bool UsesThreadaAf AGE í get; ]) 

public Conditionvariable [een ka tea TS ( get; 


hi 


Intentionally similar to CLR S existing System. Threading.Monitor 

Consistent enter/exit methods ing, gueryin and integration with other 
Maresa tta Te e ya rna [TS 

Concrete implementation c onitors) SpinLock (non-blocking) 
ReaderWriterLock, Mutex (Windows), Semaphore (Windows) 





Az egységesített lock osztályok absztrakt váza 


működő tranzakció-kezelésnek az adatbázis- 
szerverekben. Talán kevesen tudják, de a 
, Longhorn" Serverben már elérhető lesz a 
tranzakcionális Registry és NIFS, amelyek 
kezeléséért maga a kernel felel. A Visual 
Studio , Orcas" és a .Net keretrendszer kö- 
vetkező verziójának fejlesztői azonban már a 
memória tranzakcionális kezelésén is kemé- 
nyen dolgoznak. Az előzetes tervek szerint ez 
a tranzakcionális memória nem lesz ACID, 
csak ACI (D, vagyis Durability nélküli lesz, 


azaz nem lesz célja az adatok garantált és hi- 


Description: 


Elni 


móriaterületekről készített pillanatkép (snap- 
shot) használatával fognak megvalósítani. 

Ez az elképzelés lehetővé teszi majd szá- 
munkra, hogy az alkalmazásoknak és a szá- 
laknak kevesebbszer kelljen egymásra vár- 
niuk, vagy ha ez mégis kikerülhetetlen, ak- 
kor az ehhez szükséges lockolást ne a fej- 
lesztőnek kelljen leprogramoznia, hanem 
kezelje le a keretrendszer automatikusan. 
Összességében várhatóan csökkenni fog a 
szálak közti adatfüggőségek száma és jelentő- 
sége, vagyis könnyebben lehet az egyes szála- 


kat külön processzormagokon futtatni. 


A meglévő megoldások 
egyszerűsítése 

A PLINO-en és a tranzakcionális memórián 
kívül kisebb, de hasonlóan hasznos újdonsá- 
gok is érkeznek a .Net keretrendszer új (har- 
madikat követő) változatában. [de sorolható 
a hagyományos lockolás programozásának 
egyszerűsítése, amit elsősorban a lock-osztá- 
lyok egységesítésével és absztrakciójával ér- 
tek el. A másik terület, ami még kérdéses, 


hogy mennyire integrálódik az új rendszerbe 





(9 LINO Project Sample Ouery Explorer 
2-4 101 LINO Ouery Samples 

a. 4 Restriction Operators 

4.4 Projection Operators 


expressions over the two. 


This sample shows hovwv to efficiently join elements of two seguences based on eguality between key He 


a. 84 Partitioning Operators 
a. 4 ordering Operators 
a) Ld Grouping Operators 
4 L4 Set Operators 
a. Conversion Operators 
4.4 Element Operators 
(a) a Generation Operators 
a. Ouantifiers 
4. Aggregate Operators 
a. 4 Miscellaneous Operators 
a. 4 custom Seguence Operators 
4.8 Ouery Execution 
A- (41 Join Operators 
[2] Cross Join 
(2 Group Join 
[2 cross Join with Group Join 
[d Left Outer Join 
a. " sample Data 7 





a. 58 101-- DLing Ouery Samples 


Code: 


public void Ling102() í 
stringL[] categories z new string[]í 
"Beverages" , 
"condiments" § 
"vegetables" ő 
,Dairy Products", 
"Seafood" 3; 


List-Product: products - GetProductList(); 


var 
Ért c in categories 
join p in products on c eguals p.Category 
select new íf Category - c, p.ProductName 3; 


foreach (var v in 


sinai 
console.writeLine(v.ProductName 4 ": " 4 v.Category); 


(b) Run Sample! 


Output: 


(chai: Beverages 











ma. 58 101 XLing Ouery Samples 
a. A 101 LINO over DataSet Samples 
a. áá Bonus: XOuery Use Cases 


chang: Bever ages 

Guaraná Fantástica: Beverages 
sasguatch Ale: Beverages 

" Steeleye Stout: Beverages 
cöőte de Blaye: Beverages 


és a hozzá tartozó memóriát minden egyes alkalom- 
mal teljesen feleslegesen írjuk felül. Ez a teljesítmény 
csökkenését idézi elő, mivel gyakorlatilag a cache Épeál EGEEGÁS HÁÁT Nt 

JAS § Aze MT et te Lumberjack Lager: Beverages 
csak az adott szál pillanatnyi futásáig bír tényleges outback Lager: Beverages 


Rhönbráu Klosterbier: Beverages 
értékkel, és a következő szál már ismét nem talál Aniseed syrup: condimen 
magának semmi hasznosat a cache-ekben. 

Természetesen gyakran nem élhetünk az ideális 
megoldással, elvégre az esetek többségében nem- 
csak az számít, hogy egy adott szál mennyire gyor- 
san végez teendőivel, hanem az is lényeges, hogy 
hány beérkező kérést tudunk belátható időn belül 
kiszolgálni. Éppen ezért egy magra egynél több szá- 
lat is szokás ráengedni — ilyenkor az egyidejűleg ki- 
szolgálható szálak száma és az egyes szálak lefutási 
ideje között kell megtalálni az egyensúlyt. 
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jAniseed Syrup: cCondiments 











Egy érdekes LINO-példa a sok közül 


bamentes tárolása, de ezt maga a memória 
sem garantálta soha). 

Lényegében , atomic", vagyis megbontha- 
tatlan blokkokat tudunk majd definiálni 
a kódunkban, ezek garantáltan egy kon- 
zisztens memóriaállapotban fognak lefutni, 


amit vagy lockolással, vagy a használt me- 





chef Anton"s Cajun ke condiments 
chef Anton"s Gumbo Mix: Condi 

Grandma"s Boysenberry Spread: Condiments 
Northwoods Cranberry Sauce: Condiments 


ments 


az aszinkron hívások kényelmesebb kezelése, 

amire szintén több jó megoldást tesztelnek a 

Microsoft fejlesztői és kutatói, hogy még egy- 

szerűbbé tegyék számunkra a párhuzamosság 
problémáinak kezelését. 

Budai Péter 

(i-pbudai(oOmicrosoft.com) Microsoft Magyarország 


Microsoft TechNet 
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A PARANCSNOKI 


FÜLKÉBEN ÜLVE 


Mi az informatikus feladata egy meglévő rendszer 


üzemeltetésekor? Ismernie kell azt minden részletében. Az adott 


rendszer minden felmerülő és meglévő hibájáról tudnia kell. 


A hibákat a lehető leghamarabb ki kell javítania 


— System Center Operations Manager 2007. 


yakorlatilag a cél már jól ismert: garantálni kell az informatikai rendszer rendelke- 
zésre állását az azt használók számára. Sokan persze úgy gondolják, hogy egy rend- 
szergazda elsődleges feladata új rendszerek kiépítése, továbbfejlesztése, ami egyes 
esetekben igaz is lehet, de ezt munkahelye válogatja. Az igazság azonban gyakran az, hogy a 
vállalatok számára az informatika csupán egy eszköz a sok közül, ami az üzletmenet hatékony- 
ságának növelését szolgálja - épp ezért nem meglepő, hogy általában újabb és újabb informati- 
kai beruházások helyett inkább a meglévő infrastruktúra karbantartását tekintik feladatnak. 

Egy kisebb vállalatnál gyakran egyetlen rendszergazda is elegendő ehhez, aki lehet, hogy 
egyszerre több kisebb cég rendszerét is karbantartja, többnyire manuális munkával. Nem 
ritka, hogy a rendszergazda a helyszínen próbálja meg nagy küzdelmek árán megoldani a fel 
merült problémákat, miután azt a cég alkalmazottai jelzik neki. Ha azonban egy nagyobb vál 
lalatról van szó több szerverrel és több száz számítógéppel, esetleg több távoli telephellyel, ott 
felmerül az igény a karbantartási folyamatok egyszerűsítésére, gyorsítására. Ugyancsak komo- 
lyabb technikai segítségre van szüksége annak az informatikusnak vagy szolgáltató cégnek, 
aki vagy amely egyszerre lényegesen több vállalatnak szeretne informatikai támogatást biztosí- 
tani, ráadásul preferáltan távolról, az interneten keresztül. 

De igazából bárkinek, aki komolyan veszi egy informatikai rendszer üzemeltetését, el kell 
gondolkodnia azon, hogyan tehetné elégedettebbé a rendszer felhasználóit azáltal, hogy na- 
gyobb rendelkezésre állást és gyorsabb problémamegoldást garantál a számukra. 

A legkézenfekvőbb, ha a karbantartási teendőket és a hozzájuk kapcsolódó folyamato- 
kat tekintjük át, és megnézzük, hogyan segítenek ebben már meglévő módszerek és szoft 
verek. Természetesen számtalan szoftver áll ehhez rendelkezésre, mi azonban most kiemel 
ten a Microsoft System Center Operations Manager 2007-tel (SCOM), illetve elődjével, a 
Microsoft Operations Manager 2005-tel fogunk foglalkozni, illetve érintőlegesen a System 
Center-család többi tagjával. 


Miből áll a rendszerem? 
Amikor új kolléga érkezik a fedélzetre, természetesen az első feladat, hogy átlássa a rendszert, 
aminek az üzemeltetéséért felelős lesz. Ha rendelkezésre áll a rendszer pontos felépítésének 


leírása vagy modellje, az rengeteget segíthet nemcsak a karbantartás, hanem a későbbi rend- 
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szerfejlesztések, változtatások során is. Egy 
ilyen rendszermodellt folyamatosan karban- 
tartani manuális eszközökkel meglehetősen 
nehéz feladat, különösen egy nagyobb válla- 
lat esetében. 

Az Operations Manager képes arra, hogy 
feltérképezze az adott hálózat számítógépeit, 
és az azokon található szolgáltatásokat, de 
ezeket akár kézzel is módosíthatjuk utána, 
igényeink szerint. Mindez egy olyan élő mo- 
dellbe kerül bele, aminek segítségével folya- 
matosan nyomon tudjuk követni ezeknek a 
komponenseknek a változásait és az állapo- 
tát is. A 2007-es Operations Manager a fel 
térképezést az Active Directory segítségével 
is el tudja végezni, így akár egyszerűen egy 
egész OU-t is megadhatunk, amihez ha ké- 
sőbb új számítógépet rendelünk, az máris 
bekerül a felügyelt gépek közé, és automa- 
tikusan feltelepül rá minden szükséges fel 
ügyeleti összetevő. 

ASCOM a hozzá kapcsolódó Management 
Packek segítségével képes adott gyártók szol 
gáltatásait felismerni, azok jellemzői alapján 
(például a registry, a nyitott portok, a futó 
servicek vizsgálatával). Amelyik szoftverhez 
elérhető ilyen Management Pack, arról az 
Operations Manager gyakorlatilag mindent 
tudni fog, beleértve azt is, hogy milyen al 


komponensekre bontható tovább, és milyen 


ya 
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más rendszerkomponensekre van szüksége 
ahhoz, hogy az adott szolgáltatás megfelelően 
működjön. A Microsoft valamennyi szerver- 
szoftveréhez készít Management Packet (és 
ezek ingyenesen elérhetőek), így azok auto- 
matikus felderítése a hálózaton gyakorlatilag 
garantált. 

Saját alkalmazásaink és szervermegoldá- 
saink felismerése azonban általában nem 
automatizálható, azokat kézzel kell felvenni 
a SCOM-ba, vagy gyártanunk kell hozzá egy 
Management Packet magunknak. Ebben az 
elosztott rendszerek komplex modelljeinek 
tervezésére alkalmas felület is segítségünkre 
siet, ahol pontosan definiálhatjuk, hogy me- 
lyik komponensünk mely más komponen- 
sektől és milyen módon függ. A SCOM arra 
is képes, hogy hardverkomponenseket fedez- 
zen fel és felügyeljen, beleértve a hálózati esz- 
közöket, például routereket is, ha rendelke- 
zünk ehhez szükséges Management Packkel. 

Az Il. ábrán látható modell valójában 
olyan XML állományok halmazaként kép- 
zelhető el, amelyek mind-mind egy adott 
komponenst és annak viszonyát írják le a 
külvilággal, illetve azt, hogy milyen állapotai 
lehetnek, és milyen követelményei vannak 
másokkal szemben. Ezt az XML-állományt 
az SDM, vagyis a System Definition Modell 


séma írja le, ami nem csupán a rendszerme- 


dául az Exchange Server 2007 felügyeletéről, 
mint az Exchange saját fejlesztőcsapata? 
Ahhoz azonban, hogy tudjuk, hogy rend- 
szerünk valóban jól működik, azt megfigyelő 
, ügynökökre" van szükségünk. Ezek persze 


lehetnének emberek is, akik percenként rá- 


— 
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mét segít a Management Pack előre meghatá- 
rozott értékekkel. 

Az Operations Managerrel lehetőség van 
a távoli gépek Agentless, vagyis Agentek 
nélküli felügyeletére is; ilyenkor a szerver 
adott időközönként , pollozza" - kérdezgeti 
- az adott gépet állapotá- 
ról, azonban ez nagyobb 


terhet ró a szerverre, és 
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2. ábra. A felügyelt gépek és a rajtuk futó szolgáltatások állapota MOM 2005-tel 


néznek az eseménynaplóra, vagy egy teljesít 
mény-mérőszámra, azonban az Operations 
Manager ezt képes automatizált szoftverkom- 
ponensekkel is kiváltani. Ezek az úgyneve- 
zett Agentek. Az Agenteket az informatikai 
rendszer feltérképezésekor automatikusan 
telepíteni lehet a megfigyelt számítógépek- 


re, ilyenkor az Agent fo- 








lyamatosan tájékoztatja 
a SCOM szervert a fel 
ügyelt komponensek álla- 


potáról, teljesítményéről, 


79 9... [le eeee melee elme ee eten er eres Ma: —eesermemsmrne .- SE eseményeiről. 
ks vel Ezek az adatok beke- 
; rülnek a SCOM szerver 
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(2. ábra), és ebből bár 





1. ábra. Egy szolgáltatás felépítése és dependenciái 


nedzsment kapcsán lesz érdekes a jövőben. 
Itt érdemes megemlíteni, hogy már most, a 
Visual Studio 2005 elosztott rendszerek mo- 
dellezésére használható felülete is SDM-eket 


ment el, ami sok mindent előrejelez. 


Minden jól működik? 

A Management Packeket szinte mindig olya- 
nok készítik, akik a lehető legjobban ismerik 
azt a komponenst, amit felügyelni szeret 
nénk: ez általában a komponens saját fej- 


lesztőit jelenti. Elvégre ki tudna többet pél 


K 


mely pillanatban nagy 

biztonsággal meg lehet ál 
lapítani, hogy mely pontokon van esetleg 
probléma a rendszerünkkel. Ebben az álla- 
pot, vagy State-nézet van a segítségünkre 
a SCOM konzoljában. Az, hogy egy adott 
komponens milyen állapotú, nagyon sok 
mindentől függhet: például az aktuális terhe- 
lésétől, illetve olyan más, hozzá tartozó kom- 
ponensek állapotától, amelyek befolyással 
vannak rá. Hogy mikor látszik számunkra 
a SCOM konzoljában egy komponens hibás 
állapotúnak, az a lehető legapróbb részlete- 


kig beállítható, de ebben természetesen is- 





Last refreste TÍ2Gf2004 11:19:25 AM kzalhost 


űj megvalósítani is nehe- 


zebb, mint az Agent ala- 


pú felügyeletet. 

A SCOM arra is alkal 
mas, hogy egy szolgálta- 
tás elérhetőségét úgyne- 
vezett szintetikus tranz- 
akciókat kezdeményezve 
állapítsa meg - elképzel 
hető ugyanis olyan eset, 


hogy egy szolgáltatás fut, 





és a menedzsmentszerver 
el is éri azt, de a kliensek 
nem. Az ilyen esetekről 
úgy értesülhetünk, ha , figyelőket" helyezünk 
el egyes kliensgépeken, amelyek bizonyos idő- 
közönként megpróbálják működésre bírni az 
adott szolgáltatást, ennek eredményét pedig 


továbbítják a SCOM szerver felé. 


Mi történt? Mit kell reagálni erre? 

A hiba az esetek többségében nem elszigetelt 
esemény, hanem fennálló állapot, ami addig 
nem is nagyon változik, amíg el nem hárít 
juk. Azonban már a hibák legelső jelei is 
események formájában érnek el hozzánk. A 
SCOM esetében a felügyelt szolgáltatások a 
rajtuk lévő komponensekkel kapcsolatos ese- 
ménynapló-bejegyzéseket és teljesítményada- 
tokat is továbbítják a menedzsmentszerver- 
nek, így már a legelső figyelmeztetésekről is 
értesülhetünk, még ha azok nem is idézik elő 
a komponensek állapotának hibásra változá- 
sát. Az SCOM a legtöbb adathoz WMLlekér- 
dezések futtatásával jut hozzá, ami gyakorla- 
tilag teljesen tűzfalbarát módon működik, a 
WS-Managementen keresztül is. 

Amikor egy komponens állapotát vizsgál 
juk, rögtön láthatjuk azokat az eseménye- 
ket, amelyek vele történtek. Ha például az 
Exchange szerverünk nem működik megfele- 
lően, akkor azokat a kiváltó eseményeket, 
amelyek ennek a ténynek a megállapításához 
voltak szükségesek (nem indult el a szolgálta- 


tás vagy valamiért leállt) máris megtekinthet 


Microsoft TechNet 


zt 
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jük. Ilyenkor a Management Packben tárolt 
rengeteg információ (gyakorlatilag egy tudás- 
bázis) segít abban, hogy mik lehetnek ennek 
a hibának a legvalószínűbb okai, és megol 


dást is kínál rá, amennyiben van ötlete. 


Computer Time Last Modífied Resolution State 
CONTOSO-OCA  6/16/2004 12-1... 
CONTOSÓ-OC OS — éfléf2O04 12-1 
NYC-MSG-O TI712004. 11204:,., 
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CONTOSO-OCGI  SÍZBÍZOOA 12-39... 
CONTOSÓOCÁÓN — ÉjIS[200A S-00: 
CONTOSO-OCO6 — 6/11/2004 1:35:... 
CONTOSO-OCOZ — Éf7/200A 10-20: 
CABO-DCAI 6/11/2004 1236:... 
CONTÓSO-MONIT  SJ27/2004 1:16t 
CONTOSO-DC-O6 — 6/11/2004 1237:... 
CONTOSO-OCÓL — Éf10Jf2O0A 6-121 
CONTOSO-DCAVS  6/11/2004 1:38:... 
CONTOSOOCAS  f16fZO0A 2-2: 
CONTOSO-DC-OS — 6/15/2004 8-04:... 
CONTOSO-OCO4  S/29/2004 12-2... 
CONTOSO-OCOR — 6f16/2004 3:12:... 
CONTOSO-OCOR — 6/14/2004 10-1... 
CONTOSO-OC-O9 — 6/fi6/2004 2-51;... 


e—y 
Propertios , Cizítom Properties . Events " v Prodixt Knowiedge ! Comgany Kinredga ! History 
Desznyton: Name; 
The Remote Access Connection Manager service dopondsontha — Szverty: Sarvce 
Telephony serve vihih foded to start becsisée of the following Resolution State: 
CONTOSO 


error: Dornsin: 
The service csok be started, ether becszús R ís dsatked or 
Computer; CONTOSO-DC-04 
adon K hop ng ante ddrélest dssódíájáöyűtt ls Time of First Event: SEZAJZÓOH 12:17:03 AM 


Time of Last Event: 6f16f2004 12:12:07 AM 
Alert löteneyi 


The service or driver faed to start. 
Unavadabie 





mindenre hatással lehet. Ha például egy- 
szerre három szolgáltatásunk leáll, tudjuk-e, 
hogy mi a teendő? Egyenként kelle velük 
foglalkozni, vagy lehet, hogy mindhárom 
hiba egy dologra vezethető vissza? Honnan 
tudjuk, hogy ha nem mű- 
ködik egy telephelyen a 
levelezés, akkor milyen 
mélyre kell leásnunk ah- 
hoz, hogy a valódi hibát 
megtaláljuk? Lehet, hogy 
az Active Directory lesz a 
hiba valódi oka, és nem 
is az Exchange szerver 
vagy a hálózati 

Ha rendelkezésünkre 
áll rendszerünk élő mo- 
dellje, ezekre a kérdések: 


re szinte azonnal választ 


ke 
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A SCOM 2007-es változata a MOM 2005- 
tel ellentétben ilyenkor nemcsak scripteket, 
szöveges ajánlásokat vagy KB-cikkeket ajánl 
fel (3. ábra), hanem arra is lehetőséget ad, 
hogy egy adott megoldást (például a szol 
gáltatás újraindítását vagy egy karbantartó 
script indítását) egyetlen gombnyomással el 
indíthassunk. Természetesen ezt a hibákat és 
eseményeket bemutató tudásbázist mi is bő- 
víthetjük, így a mi környezetünkben gyakran 
előforduló hibákra akár egy gombnyomással 
megoldást szolgáltathatunk még akkor is, ha 
éppen szabadságon vagyunk. 

Ha időben látunk minden eseményt, akkor 
még a kezdeteknél észrevehetünk olyan hibá- 
kat, amelyek később más komponensekre is 
kihathatnak, hiszen általában az első hiba a 
valódi hibaok. Azonban vannak olyan komp- 
lex esetek, amikor több, egymástól teljesen el 
szigetelt hiba fordul elő, vagy még egy koráb- 
bi hiba fennáll, miközben egy újabb érkezik. 
Mit tehetünk, ha a tényleges hibát valójában 
más alkomponensek hibái okozzák, amiket 
szintén alaposabban meg kellene vizsgálnunk 
a probléma elhárításához, ahelyett, hogy a va- 
lódi hiba mellékhatásait gyógyítjuk? 


Mi a hiba valódi oka? 


A hiba valódi okának megkeresése általá- 
ban meglehetősen fáradságos tevékenység. 
A rendszer komponensei ugyanis gyakorla- 


tilag egy gráfot alkotnak, és szinte minden 
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3. ábra. A beérkezett hibák, figyelmeztetések és ezek részletei MOM 2005-tel 





kaphatunk. Szerencsére 
a SCOM pontosan tisztá- 
ban van az egyes kompo- 
nensek állapotával. Ha vizuálisan képzeljük 
el a komponensek viszonyát egymáshoz ké- 
pest, szinte biztos, hogy ott lesz a probléma, 


ami a legmélyebben talál 


juk, hogy melyek azok a kliensalkalmazások, 
amelyek gyakran lefagynak, és vélhetően a 


legtöbb felhasználói panaszhoz vezetnek. 


Hogyan tudok több céget/telephelyet 
távolról felügyelni? 

Maga a menedzsmentszerver MMC:s felület 
tel rendelkezik, ami természetesen akár tá- 
volról is elérhető, de mindezek mellett hozzá- 
férhetünk egy webes felügyeleti oldalhoz is. 

A SCOM szervereket könnyen össze lehet 
kötni egymással (vagy más gyártók hasonló 
megoldásaival), akár HITTPS-en keresztül is 
a WS-Management protokoll segítségével. 
Érdemes felügyelt telephelyenként egy-egy 
SCOM szervert elhelyezni, hogy az lokáli- 
san, hatékonyan tudja gyűjteni az adatokat a 
telephely gépeiről. 

Ezeket a távoli menedzsmentszervereket 
egy közös szerverről tudjuk a legkényelme- 
sebben figyelni, aggregálva az egyes SCOM 
szerverek által gyűjtött adatokat. 

Ez a felállás (4. ábra) nemcsak a nagyobb 
vállalatoknál lehet jó megoldás arra, hogy 


teljes hálózatukat központosítva tudják fel 





ható a rendszerünkben, m 


vegen 









és bizonyítottan hibás. 
A többi hiba várhatóan 
csak ennek következmé- 
nye lesz. A SCOM segít 
ségével egy hiba okának 


feltárása sokkal egysze- 





rűbb, mint más módsze- 
rekkel, 


látható, melyik az a pont, 


hiszen azonnal 









amelyet elsőként vizsgál 
nunk kell, ha beérkezik 
az első panasz, hogy nem Few 
működik a levelezés. Sőt, 
az is lehet, hogy mi vesz- 
szük észre a hibát elsőként, és még az előtt el 
tudjuk hárítani, hogy bárki munkáját komo- 
lyabban akadályozta volna. 


Hogyan mutassam meg 

az ÍT rendelkezésre állását? 

A SCOM segítségével jelentéseket is készít 
hetünk (immár SOL Server 2005 Reporting 
Services alapokon) az informatikai rendsze- 
rünk rendelkezésére állásáról, az egyes tel 
jesítménymutatókról vagy például a szolgál 
tatások meghibásodásának időpontjairól, 


arányáról. Azt is pontosan megmutathat 
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4. ábra. A System Center Essentials konzolja 


ügyelni, hanem akár arra is alkalmas lehet, 
hogy egy kisebb cég legyen képes felügyelni 
más cégeket távolról. A megoldás lényege: 
mindegyiknél telepítünk egy SCOM-ot (vagy 
a részben kisebb tudású, de a kisvállalatok 
számára sokszor hasznosabb System Center 
Essentialst), valamint a szolgáltató maga ren- 
delkezik egy központi SCOM-mal, ahonnan 
folyamatosan szemmel tudja tartani, hogy 
mely felügyelt cégnél milyen az informatikai 
rendszer aktuális állapota. 
Budai Péter 
(i-pbudai(oOmicrosoft.com) Microsoft Magyarország 


Ki 
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A VVINDOWS 


VISTA 


BEVEZETÉSE 


Az új rendszert támogató új és megújult technológiák. 


smerjük meg, hogyan válhat gyorsabbá és egyszerűbbé az asztali számítógépek bevezeté- 
se/telepítése az új technológiák segítségével! Bár sok hasznos újdonság érkezik a Vistában, 


azonban a bevezetésért felelős informatikusok csak egy dolgot kérdeznek: az eddigieknél 


könnyebb lesz-e ezt bevezetni. 


A termék bevezetése alapvetően három pilléren nyugszik. 


A platform újításai. A Windows Vista új image-elő (lemezképkezelő) technológiát, alkal 
mazásokat és eszközöket tartalmaz az image-ek készítésére, módosítására, testreszabására 
(az egyéni igényeknek megfelelően) és alkalmazására. 

Az alkalmazások kompatibilitása. A Vista a Windows XP-n futó alkalmazások legnagyobb 
részét probléma nélkül futtatja, valamint a régebbi alkalmazásokat tekintve, a Windows 
XP-vel összehasonlítva megnövelt kompatibilitással rendelkezik a régi verziókat emuláló ré- 
teg továbbfejlesztésével. 

A bevezetés módja. A Windows XP és régebbi verzióinak bevezetésekor külső gyártótól 
származó image-technológiákat kellett használnunk a rendszer bevezetéséhez. Az image- 
technológiák beépülése révén most már egyszerűbben és külső szoftverek nélkül is megva- 


lósíthatjuk ezt a folyamatot. 
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A bevezetési folyamatot segítő új technológiák 


Modularizáció. A Vista teljesen különálló, csomagszerű részekből épül fel, ezek kihaszná- 
lásával a legapróbb részletekig testreszabhatjuk az összetevők működését, és igényeiknek 
megfelelően konfigurálhatjuk őket. A modularizáció ugyancsak segítséget nyújt a külső 
csomagok (driverek, alkalmazások, nyelvi felületek) és frissítések rendszerbe illesztésében, 
azok különálló telepítése nélkül. Ez nyújt lehetőséget arra is, hogy a Microsoft az operációs 
rendszer részeit egyenként frissítse és javítsa, megelőzve az egyéb összetevők nem megfele- 
lő működését. A felhasználói felület megjelenési nyelvét is modulként befolyásolhatjuk a 
rendszertől függetlenül (vagyis MUI csomagok használata nélkül), egyszerűen a telepítő- 
készlet testre szabásával. 

Windows Imaging Format (WIM). A WIM egy új, fájl alapú image-formátum, amelynek 
használatával lehetőségünk van egyetlen image-et több, eltérő hardverkonfigurációval ren- 
delkező számítógépre telepíteni, mindezt gépenként egyedi beállítások használatával. A 
WIM image-fájlok kezelése egyszerű, anélkül telepíthetünk/törölhetünk Windows-össze- 
tevőket, drivereket, alkalmazásokat és frissítéseket, hogy az image-et bebootolnánk. 
Egységes XML-válaszfájl. Az eddigi, külön-külön előállítandó válaszfájlok helyett most 
már elegendő egyetlen XML fájl is, ami ráadásul többféle konfiguráció kezelésére is képes, 


hála a hardverfüggetlenségnek és a modularitásnak. 


A bevezetés eszközei (a Windows Automated Installation Toolkit - a WAIK - részei): 


Application Compatibility Toolkit. A vállalatnál használt alkalmazások és a Vista kompa- 


tibilitásának ellenőrzésére és javítására. 
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n User State Migration TIool (USMT). A 
felhasználók Windows 2000 vagy Win- 
dows XP alatt tárolt beállításainak és sze- 
mélyes fájljainak automatikus migrálása a 
Windows Vista platformra. 

a ImageX. WIM image-fájlok létrehozása és 
fájlszintű szerkesztése. 

Windows System Ímage Manager (WSIM). 
A Windows Vista WIM image-fájlok kom- 
ponens alapú módosítása. A rendszerkom- 
ponensek beállításainak módosítása és kül 
ső összetevők hozzáadása (például nyelvek 
és driverek) is ezzel lehetséges, mindezt 
egyetlen unattend.xml létrehozásával tehet 
jük meg. 

Windows Preinstallation Environment 
(WinPE). Rendszerbeállítások módosítá- 
sa (például formázás és particionálás) az 
operációs rendszer elindítása nélkül. 
Habár a modularizáció és a WIM-formá- 

tum már külön-külön is sokat könnyít a te- 

lepítések létrehozásán, a két technológiát 
együtt alkalmazva még tovább egyszerűsít 
hetjük a telepítés folyamatát. 

Application Compatibility Toolkit (ACT). 
Az asztali operációs rendszerek cseréje a raj- 
tuk futó alkalmazások miatt alapos tervezést 
és körültekintést igényel. Különös gondot kell 
fordítani a már telepített programok Vistával 
való kompatibilitásának ellenőrzésére. Az 
ACT az alábbiakban segít nekünk: 
an APl-kompatibiliítás biztosítása. A külső 

szoftvergyártók számára elérhetővé tett in- 

formációk alapján alkalmazásainkat köny- 
nyen alakíthatják Vista-kompatibilissá. 

a. Software Inventory Analyzer. A vállalat 
nál telepített PC-ken lévő szoftverekről 


leltárt készít, központi helyen tárolja, ösz- 
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szesíti és összeveti az ACI webes adatbá- 

zisával, megjeleníti az esetleges problémás 

számítógépeket és alkalmazásokat. 

a Filtering Analyzer. Egységes lehetőséget 
nyújt arra, hogy a felhasználók hibát je- 
lezhessenek a rendszergazdának, ameny- 
nyiben egy alkalmazás Vista alatt nem 
működik megfelelően. Ugyanekkor auto- 
matikus frissítéskeresés is végrehajtódik 
az adott szoftverre. 

WIM. Lássuk az új imageformátumot! A 


manapság elérhető image-technológiák (pél 


Alkalmazás- 
kompatibilitás Az image 


a patcheken és a drivereken át az alkalmazáso- 
kig bármit törölhetünk vagy hozzáadhatunk 
az image-hez egy új image létrehozása nélkül, 
értékes órákat spórolva meg. Eddig egy szoft 
verjavítás image-be illesztése csak az image 
egy gépre való feltelepítésével, a patch alkal 
mazásával és az image újragenerálásával tör- 
ténhetett meg; a Vistával azonban nemes egy- 
szerűséggel offline is megtehetjük ugyanezt. 

Nagyon fontos a rugalmasság szempontjá- 
ból is, hogy a WIM nem szektor, hanem fájl 
alapú, hiszen így tetszőleges méretű partíció- 
ra telepíthetjük, nem kell pontos 
partícióméreteket követni. Egy 
WIM-image telepítésekor nem 


kötelező a teljes partíciót formáz- 


Teendők ellenőrzése, összeállítása és Telepítés ni, annak tartalma megmarad- 
migrációs testre szabása hat, csak az operációs rendszer 
scriptek cserélődik alatta, gyakorlatilag 

ImageX USMI adatvesztés nélkül. 
Vistás ACT Windows System. WDS Fejlesztők, figyelem! Egy új 
eszközök .  USMT Image Manager Image alapú APL a WIMGAPI segítségével 
Sysprep telepítés 





dául a Ghost) által használt formátumok 
általában szektor alapúak, ezzel szemben a 
fájl alapú WIM sokkal több előnyt nyújt szá- 
munkra. A WIM-formátum hardvertől füg- 
getlen, így tetszőleges számú és fajtájú hard- 
verkonfiguráción is működőképes ugyanaz 
az image. 

Mindezek mellett egy .WIM fájl több 
image-et is tud tárolni; erre a legjobb példa, 
hogy a Windows Vista végleges dobozos ver- 
ziójának DVDi ugyanazt az image-et fogják 
tartalmazni, és termékkulcstól függően a 
fájlból más és más verziójú operációs rend- 
szer csomagolódik ki. 

Ugyancsak lehetőségünk lesz például az 
alkalmazásokat külön image-ben tárolni a 
WIM fájlon belül, tehát akár gépenként el 
dönteni, hogy melyekre mely alkalmazás- 
készlet kerül. A WIM támogatja a single in- 
stancinget, ezzel jelentősen csökkentve a fájl 
méretét. A single instancing használatával a 
két komponensben megtalálható azonos fáj- 
lokat csak egy példányban tároljuk, és a má- 
sik fájlnál csak egy hivatkozást hozunk létre 
(például több Windows-image esetén egy 
WIM fájlban: az operációs rendszer fájljai 
szinte teljesen megegyeznek, így akár 30-40 
százalékkal is csökkenhet a képfájl mérete). 

Megoldható lesz az image offline szervize 


is. Az operációs rendszer összetevőitől kezdve 


OKTÓBER-NOVEMBER 


tetszőlegesen  turkálhatunk az 

imagefájlokban, erről további in- 
formációkat hamarosan az MSDN-en talál 
hatnak az érdeklődők a http://msdn.micro- 


soft.com/windowsvista címen. 


ÍmageX 

Az ImageX egy igazán lényegre törő prog- 
ram, ezért szeretik már most is sokan. Egy 
egyszerű, parancssoros eszköz, hasonlóan 
például az Xcopyhoz. Alaphelyzetben az esz- 
köz arra képes, hogy egy meglévő kötetről 
készítsen nekünk egy (WIM állo- 
mányt, vagy hogy egy kötetre egy 
már korábban létrehozott .WIM- 
et csomagoljunk ki teljesen vagy 
igény szerint részlegesen. Előbbit 
nemes egyszerűséggel az 

imagex /capture C: image.wim 
"Name" 
parancs használatával tudjuk el 
érni, utóbbihoz pedig az 

imagex /apply image.wim 1 
utasítást kell kiadni. Ugye, mi 
lyen egyszerű? 

Az ImageX ezenkívül lehetősé- 
get nyújt az image-ek felcsatolá- 
sára, ami után úgy bütykölhetünk a .WIM 
fájlon, mintha valóban telepítettük volna 
az image-et (gyakorlatilag egy betűjelet ren- 
delünk hozzá, ami egy virtuális merevlemez- 


ként érhető el ezután). 





Egy .WIM szerkezete 


Iza! 
Az ImageX főbb parancsai: 

/append: egy image hozzáadása a WIM-fájl 

hoz 

/apply: egy WIM-ben található image kibon- 

tása a megadott meghajtóra 

/capture: image létrehozása egy új WIM- 

fájlba 

/commit: a felcsatolt image módosításainak 

érvényesítése a WIM-ben 

/compress: a tömörítés módjának állítása 

/config: imagex-beállítások módosítása 

/delete: image törlése a WIM fájlból 

/dir: N/IM-ben lévő image tartalmának lis- 

tázása 

/export: image átvitele két WIM között 

/info: image-adatok kivitele XML-be 

/ref: mélyreferenciák módosítása (csak pro- 

fiknak) 

/split: image felosztása több, kisebb részre 

/verify: adatellenőrzés, átviteli hibák kiszű- 

rése 

/mount: image csatolása WIM-ből 

/mountrw: image csatolása WIMt-ből - írá- 

si joggal 

/unmount: csatolás megszüntetése 


/t: súgó 


Windows System Image Manager 

A Windows System Image Manager a Vista 
telepítésének testreszabásához használt 
XMLuwválaszfájlok szerkesztésére használható 
eszköz. Segítségével a rendszer összetevőit 
modulonként tudjuk konfigurálni, például 


megváltoztathatjuk vele az Internet Explorer 


WIM 





AppSet1: 


Size AppSet2: 


Office, Speciális 
driverek 


nIatisat ási e 
Visual 
Studio 


pénzügyi 
alkalmazás 





kezdőlapját, vagy mondjuk letilthatjuk a kép- 
ernyővédőt. 

A WSIM használatához mindenekelőtt te- 
lepítenünk kell azt az internetről letöltve, de 


a resource kit részeként is elérhetjük. A tele- 
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pített WSIM-et futtatva létre kell hoznunk 
egy katalógust. A katalógus voltaképp egy 
indexfájl, aminek létrehozásakor a program 
elemzi a WIM-fájlban elérhető beállítási le- 


a tet ge 
File — Edit Insert Tools Help 
8 3 B ld! 4 


) Ig e 














landó összetevőt (a WSIM automatikusan a 

megfelelő fázisba helyezi el a módosításokat), 

és a jobb oldali panelen kedvünk szerint mó- 
dosítani az elérhető beállításokat. 

A WSIM által kreált vá- 

laszfájl használatához vagy 

a Windows 


Services lehetőségeit kell 


Deployment 
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A Windows System Image Manager felülete 


hetőségeket és tárolja azokat. Ezek után egy 
új, üres (vagy létező) válaszfájlt kell megnyit 
nunk, amibe elmentjük a választott módo- 
sításokat. Ha ezzel is megvagyunk, meg kell 
adnunk egy disztribúciós megosztást, ahova 
a telepítéshez szükséges fájlokat helyezi el a 
WSIM. Ez a mappa akkor különösen fontos, 
ha külső programokat is szeretnénk az operá- 
ciós rendszerrel együtt, hálózatról telepíteni. 
A Windows telepítése jól definiált fázisok: 
ra van bontva, és a különböző beállításokat 
a telepítés más és más szakaszaiban tudjuk 
csak módosítani. (Vagyis például az Internet 
Explorer kezdőlap-beállításait természetesen 
csak akkor módosíthatjuk, amikor már a 
szükséges registry hive és -fájlok már a célszá- 
mítógépen vannak; előbb semmiképp.) 

E fázisok közül az első a WindowsPE, 
amely opcionális, és csak akkor fut le, ha a 
telepítést WinPE környezetből indítjuk. 

Az offlineServicing a telepítő első (vagy 
második, WinPE esetén) fázisa, mely a WIM- 
fájl másolásával egy időben hajtódik végre. A 
további fázisok (generalize, specialize, audit 
System, auditUser) már a WIM kicsomagolá- 
sa után hívódnak meg. 

Az oobeSystem fázis a felhasználói felület 
(OOBE - OutOfIheBoxExperience) első 
megjelenésekor hajtódik végre. 

Ezek testre szabásához nincs más dolgunk, 


mint a katalógusból kiválasztani a befolyáso- 


kg. 


A Windows Deployment 
Services gyakorlatilag az 
ADS és a RIS utóda, ami el 
érhető lesz a Windows Server 2003 SP2-ben, 
és a , Longhorn" Serverben is. 

Amennyiben úgy kényelmesebb számunk- 
ra - tekintettel a WIM hardverfüggetlen- 
ségére -, megtehetjük, hogy készítünk egy 
referenciatelepítést a válaszfájl használatával, 
majd az ImageX segítségével rögzítjük a tele- 
pített rendszert, és az alkalmazások telepíté- 
se után ezt az image-et forgalmazzuk tovább 


a megfelelő csatornákon keresztül (például 


WDS segítségével). 


Ge 
t 2 


Fontos, hogy noha a WIM önmagában 
valóban nem hardverfüggő, nem szabad el 
felejteni: az image létrehozásakor a manuális 
telepítések során sok egyedi, a számítógépre 
és a felhasználóra jellemző adat is létrejön. 
Ezeket a sysprep-pel mindenképpen ki kell 
pucolni, mielőtt több különböző konfigurá- 
ció telepítéséhez kezdenénk hozzá! 

A nagytakarításhoz a CXWindowsNSys- 
tem32NSysprep.exe /oobe /generalize /shut 
down parancsot kell futtatni. Ekkor a sys- 
prep az összes egyedi információt törli a 
számítógépről, újra engedélyezi az OOBE la- 
pokat (amelyek a telepítés után megjelennek 
- hogy a felhasználó meg tudja adni telepítés- 
kor például személyes adatait: felhasználóne- 
vét vagy egyes esetekben magát a termékkul- 
csot is). Mindezek végeztével pedig leállítja a 
számítógépet. 

Röviden összefoglalva: a WDS-WIM- 
WSIM az a három eszköz, ami fogja majd 
a kezünket a bevezetés teljes folyamatán ke- 
resztül. A WIM tartalmazza az adatokat, a 
WSIM által kreált válaszfájl a beállításokat, 
mindezt pedig a WDS juttatja el a számító- 
gépekre. 


A verziófrissítés működése, 

avagy hogyan húzzuk ki a szőnyeget 
a Windows XP lába alól 

A Windows 2000-ről Windows XP-re törté- 
nő frissítés esetén az történt, hogy a rend- 
szer a dokumentumainkat és alkalmazásain- 


kat a gépen hagyva, mindössze a Windows 


A TELEPÍTÉS LÉPÉSEI ÉS A TESTRE SZABÁS LEHETŐSÉGEI 


Telepítési fázis Mi történik? 
Downlevel-telepítés (tiszta 
telepítés/frissítés) telepítési 
forrásból indítva vagy 
WinPE-telepítés 


a Unattend.xmi 


Általános telepítési lépések 1. A lemez beállítása 





Downlevel esetén: a telepítési beállítások (telepítés helye, termékkulcs) megadása: 
a a telepítővarázslóban manuálisan vagy 


WinPE esetén: a windowsPE beállítási fázisban található válaszfájl feldolgozása 


2. A Windows Image fájl másolása a merevlemezre 
3. A rendszerindító adatok előkészítése 
4. A választájl offlineServicing beállításainak alkalmazása (külső telepítések) 


Online futási beállítások 


A Windows egyedi beállításainak létrehozása: 
a egyedi Security ID (SID) 


a Plug-and-Play eszközök telepítése 
a. Legacy-Non-PNP eszközök telepítése 
a a válaszfájl onlineServicingConfigurationPass beállításainak alkalmazása 


Windows 00BE I. 


Válaszfájl oobeSystem részének feldolgozása 


(0ut-OT-The-Box-Experience) 2. Oobe.xml tartalmi beállítások alkalmazása 
3. A Windows Vista első indítása 
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könyvtár tartalmát felülírva és a regisztrá- 
ciós adatbázis legnagyobb részének átvéte- 


lével települt. Ez az esetek nagy részében 


problémákat okozott a nem 
tökéletes visszafelé kompatibi 
litás miatt. A Windows Vista 
telepítője ezzel szemben a fÍris- 
sítő telepítés esetén is egy tisz- 
ta rendszert telepít (tehát nem 
veszi át a registryt), majd a le- 
mentett alkalmazásokat és do- 
kumentumokat egy snapshot 


ból állítja vissza. 


A Business Desktop 
Deployment Toolkit 
(BDDT) 

A BDDT eszköztára egy cso- 
magban elérhetővé teszi a 
Windows Vista és az Office 
2007 bevezetéséhez szükséges 
összes eszközt, technológiát, 


tudást és segédletet, ami szük- 


séges lehet a vállalatok szakemberei számára. 
Ami ugyancsak újdonság, hogy a Microsoft 
a BDDLt hivatalosan támogatni is fogja a 


ICT híre 
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megfelelő csatornákon keresztül, tehát prob- 
léma esetén végre lesz kihez fordulni. A 


BDDI ennek a cikknek a megjelenésekor 





( JJ d ) ControlPanel zt Welcome Center v]ép]j] Search 


Windows Vista" Ultirnate 
Intel(R) Pentium(R) M processor 1400MHz 
piss ate] 


Standard VGA Graphics Adapter 
Computer Name: BANKSJR-PC 


1. Get started with Windows (13) 


A View computer details [3 Transfer files and settings rag Connect to the Internet 
ked é 
ök Windows Ultimate Extras 


a E What s new in Windows Vista KT Personalize Windows 
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Download Windows Live Sign up online for Windows 
Toolbar Live OneCare 


64! Download Windows Live Mail Download Windows Live 
desktop 4 Messenger 


2. Offers from Microsoft (7) 
I ká: Go online to learn about 
AZ ) Windows Live 


Go online to Windows 
Marketplace 


Show all 7 items... 





(Z] Run at startup (Welcome Center can be found in Control Panel, System and Maintenance) 





A Welcome Center 


már elérhető is lesz a http://connect.micro- 
soft.com oldalon. 


A végére egy kis finomságot hagyva, ejt 













sünk pár szót a Welcome Centerről. A Wel 
come Center egy olyan alkalmazás, amelyik a 


számítógép minden egyes elindításakor meg- 


jelenik, egészen addig, amíg a 
felhasználó ki nem kapcsolja. 
A Welcome Center egyszerű, 
és központi helyen nyújt mó- 
dot arra, hogy a rendszergazda 
által kialakított lehetőségeket 
(programok telepítése, belső 
weblapok stb.) a felhasználók 
számára a rendszer automati- 


kusan felkínálja. 


Mélyebben a portálon 

A bevezetésről és az azt segítő 
technológiákról további mély, 
nagyon részletes információ- 
kat találunk a TechNet portá- 
lon, a http://www.microsoft. 
com/technet cím windowswis- 
ta pontjánál és a hamarosan 
megjelenő Resource Kitben is. 


Moldova György 


MCSE--I, MVP, MSS (v-gyomoloOmicrosoft.com) 


Microsoft Magyarország 
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Es 


WSUS 3.0 BETA 2 


Megérkezett a Microsoft központi frissítéskezelő és telepítő 


alkalmazásának következő változata, egyelőre csak tesztverzióban. 


ajdnem egy éve írtunk utoljára ezeken a hasábokon a WSUS-ról (Windows Server 
Update Services), a Microsoft kis- és középvállalatoknak szánt, központi fÍrissítés- 
kezelő és telepítő alkalmazásáról. A termék második változata akkor már hónapok 
óta bárki számára ingyenesen letölthető volt, és nagyjából a cikk írása idején érkeztek az első 
hírek arról, hogy - a szokásosnál zártabb körben - elindul a következő verzió tesztelése. Ez év 
augusztusának közepén viszont , kitárták a kapukat", így aztán a Microsoft Connect oldalon 
keresztül, megkötések nélkül lehetett jelentkezni az új WSUS tesztelésére. Mindez közvetle- 
nül a Beta 2-es verzió megjelenése előtt történt, amelyet aztán nyomban ki is próbálhattunk, 


és immár másfél hónapos tapasztalat alapján be is tudunk számolni a változásokról. 


A rögtön látható különbségek 
Az eltérések a telepítéssel kezdődnek, de ez csak féligazság: a folyamat sokkal több lépésből 
áll ugyan, viszont e lépések jelentős része már ismerős lesz minden WSUS-üzemeltetőnek. 
Azaz nem történt más, mint hogy a régebbi verziók telepítését követő 5-6 konfigurációs lépést 
(proxybeállítás, frissítésszinkronizálás, időzítés, termék és kategória, illetve nyelv kiválasztása 
stb.) integrálták egy új, Windows Server 2003 
R2 típusú varázslóba. A telepítési előfeltétele- 


EY TeTe Láb eset Update Services 3.0 Beta 2 
E File Action View Window Help 


ket tekintve már több a változás, íme a lista: 
1. Windows Server 2003 SPI - IIS6; 
2. Net Framework Version 2.0; 
3. Microsoft Report Viewer Redistributable 
2005; 
4. MMC 3.0; 
5. BIIS 2.0- és WinHTIP 5.Lfrissítések. 


CENEEJEK 
Én Update Services 
5-HA 
B- 2 bat 
2 All Updates 
6 Critical Updates 
-e4 Security Updates 
4 WSUS Updates 
5- a Computers and Groups 
.  E-gy All Computers 
ég Downstream Servers 
Í4 Synchronization Results 





Överview 
All Updates 
II Updates with errors: 


lel Updates installed/up-to-date: 
Il Updates with no status: 


; Reports 
A kakukktojás a 3. pont, ugyanis a többi 8 omen SSE denzenad látási 
már integrált (például MMC 3.0 : R2), vagy 1 KÉT tl ETL SK 
valószínűleg korábban frissített, ellenben a os 
Report Viewert külön le kell tölteni és te- A WSUS MMC( nyitóoldala 


lepíteni, bár ez abszolút egyszerű művelet. 
Sajnos, a listából az is kiderül, hogy a Windows 2000-kiszolgálókra a WSUS 3.0 már nem tele- 
píthető, viszont a következő kiszolgálóverzióra (a Windows , Longhorn" Serverre) igen. 

A telepítést nem számítva az első igazi különbség, amivel szembesülünk, a kezelőfelület 
alapjaiban történt váltás. A HITP/HTTPS-ről a MMC 3.0-ra térünk át ugyanis az új WSUS- 
szal. E cserének számos előnye van, gondoljunk csak bele például a több szerver együttes ke- 
zelésének lehetőségébe. Ezt enyhén szólva körülményesen lehet csak megoldani a korábbi ver- 
ziónál, most viszont a MMC-ben már megszokott módon (Connect to...) tetszőleges számú 
WSUSs-szervert szervezhetünk be egy konzolba. 

A megjelenítésben, a szűrésben és rendezésben is több változást hoz a kezelőfelület cseré- 
je. A WSUS 2.0-ban 4 oszlopba szervezhettük például a frissítéseket (Title, Classification, 
Release Date, Approval), a: MMC 3.0-ban viszont 15 különböző oszlopunk is lehet, azaz pél- 


ki 
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23 A 


v I Updates needed by computers: 


dául olyan extra információkat is szerepeltet 
hetünk minden sorban, mint a vonatkozó 
KB-cikk száma vagy az MSRC-kategória és 
-név. Hasznos dolog az , Apply to All Views" 
parancs is, amellyel az egyszer alaposan ki- 
gondolt oszlopkiválasztást rögzíthetjük az 
összes létező nézetre. 

A frissítések rendezésénél van még további 
újítás is: bevezették a például az Outlookban 
is látható vízszintes csoportosítást, a Írissíté- 


sek besorolását alapul véve. 


Ujdonságok a működésben 
Kicsit talán nehézkesebb lett az admin gépé- 


ről elérni a WSUS-szervert, mivel a HITE 








4 This view shows a sumrnary of the status of your updates by update view. 


Critical Updates 

MI Updates with errors: 7 
I Updates needed by computers: 3 
0 " u Updates installed/up-to-date: 0 


556 I Updates with no status: 135 
YYSUS Updates 
19 Il Updates with errors: 0 
14 .] Updates needed by computers: 0 


0 (al Updates installed/up-to-date: 0 


404 I Updates with no status: 7 


vel működő verziónál nem kellett semmit 
sem telepítenünk. Most viszont - miután 
gondoskodtunk a korábban felsorolt előfelté- 
telek 2-4. pontjának meglétéről - a telepítő 
mappájában adjuk ki a következő parancsot 


a konzol telepítéséhez: 


wsussetup.exe Console. install—1 


A korábbi cikkekben beszámoltunk azok 


Microsoft TechNet 


met 
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ról a nagyon munkaigényes praktikákról is, 
amelyek szükségesek voltak ahhoz, hogy ala- 
csonyabb jogosultsággal is lehessen használni 
a WSUS-konzolt, például a jelentések megte- 
kintése miatt. A Microsoft viszont ,kap- 
csolt", és lehetővé tette ezt az új WSUS-ban 
mindenféle extra teendő nélkül. A megoldás 
elegáns, a címtárban vagy a helyi csoportok 
között észrevehetünk a telepítés után egy 
WSUS Administrators, illetve egy WSUS 
Reporters biztonsági csoportot, ezekbe tet 
szés szerint pakolhatunk felhasználókat. 
Pillanatnyilag csak egy probléma látszik ezzel 
kapcsolatban, nevezetesen, hogy a címtár- 
ban létrejövő csoportokba hiába raktuk be a 
korlátozott felhasználót, a kliensen csak ak 


kor működött, ha a helyi Reporters csoport 


All Updates (611 updates of 672 shown, 672 total) 















Approval: " Any Except Decl "Status: Any - Z Refresh 






4 n Definition Update 1 


9 Security Update fo Hilg-etelüs 


Supersedence 
[4] Title 
9 Security Update fo Classíication 
e 


2 Security Update fo 


9 Security Update fo [/] MSRC Severity 
9 9 Security Update fo MSRC Numbers 
4 2 Definition Update 1(v] KB Articles 
9 9 Definition Update 1 Needed and Failed Count 
9 9 Windovrs Maliciou 1Jp-to-Date and Unknovén Count 
0 0 Update for Outlook 1Jp-to-Date and IUnknowin Percentage 
9 0 Security Update fo Release Date 
9 9 Update for windov Ad ATTYA TELS 
9 Cumulative securil la LEE 


(— Applyto All views em 


Oszlopmegjelenítési opciók 











9 Cumulative Securi 





ban szerepelt a tartományi fiók. Valószínűleg 
erre születik javítás a későbbiekben. 

Az előző verzióban a WSUS-kliensek cso- 
portosítása (targeting) újdonságnak számí- 
tott, ennek megfelelően bizonyos korlátok: 
kal valósult csak meg. Egy gép maximum egy 
csoport tagja lehetett, és a csoportok egy- 
másba ágyazása sem jöhetett szóba. Ez nyil 
vánvalóan az áttekinthetőség rovására ment, 
hiszen csak olyan rendszert hozhattunk lét 
re, amelyik sok csoporttal és lapos hierar- 
chiával rendelkezett. A WSUS 3.0 viszont 
változtat ezen a helyzeten, mindkét korlátot 
sikerült feloldani, így nagyobb vagy bonyo- 
lult hálózatok esetén is átlátható hierarchiát 
hozhatunk létre. 

A megerősítések területén is van fontos 
változás, bővült az automatikus megerősíté- 
sek szabályozhatósága. Készíthetünk szabá- 
lyokat (szintén az Outlookhoz hasonlítható 
módon) a különböző termékek, illetve a fris- 
sítések típusának felhasználásával, ami azért 


jó, mert könnyedén engedélyezhetjük az au- 


VLAN SEDNÁá E áá 


tomatikus telepítést a kevésbé kritikus kom- 
ponenseknél (például Office-alkalmazások), 
és óvatoskodhatunk manuális megerősítés- 
sel a fontosabb szoftvereknél. 

A jelentésekkel kapcsolatban nem beszél 
hetünk apró változásokról, csakis a teljes át 
alakulás kifejezés jöhet szóba, ugyanis tényleg 
gyökeresen más lett ez az alrendszer - nem vé- 
letlenül előfeltétel a telepítésnél említett plusz 
komponens. Egyrészt jelentős számú előzetes 
beállítási, szűrési lehetőségünk van, másrészt 
amellett, hogy a végeredmény az összes kate- 
góriában igazi vizuális élmény, nagyon részle- 
tes is, harmadrészt a jelentéseket elmenthet 
jük jól felépített Excelés pdfformátumban, 
negyedrészt a nyomtatással kapott végered- 
mény is megfelel az elvárásoknak. 

A termék frissítésével kapcsolatosan - a 
tapasztalatok szerint - sok probléma nincs, a 
Beta 2-vel helyben végzett (in-place) frissítés 
teljesen simán, mindenféle probléma nélkül 
lezajlott éles környezetben is. Iegyük hozzá, 
hogy egy viszonylag kis hálózatban működő 
WSUS-t frissítettünk (amelyiknél viszont az 
WSUS 2.0 SPI frissítésekor voltak azért ko- 
moly problémák!) gyakorlatilag csont nél 


kül, minden beállítás megmaradt, az adat 


Approval Rules XI 
Update Rules [ Advanced ] 


You can specify rules for autornatically approving new updates 
when they are synehronized. 


New Rule... . Edit... 2 Delete Run Rule 








d Install AutoDeployrment Rule 


Rule properties (click an underlined value to edit) 


When an update is in Critical Updates, Definition Updates, Security 
Updates, Update Rollups, Updates 





when an update is in áctivesyne, any Internet Security and Acceleration 
berver product, LH Setup Updates, LongHorn Server, Office 2003, 
pyindows Defender, Windows Internet Explorer 7.0 Dynamic Installer, ; 


windows Media Dynamic Installer, Windows Server 2003 


vvindows : 





1 Iltimate Extras, Windows Vista, Windows XP: 


Approve the update for all computers 





ok [/ came [/ érny I 


Szabályokat hozhatunk létre a megerősítésekhez 


bázis szintjén az átállás az SOL Server 2005 
Express Editionre szintén nem okozott prob- 
lémát (egyébként a rendszer az SOL Server 
2005 teljes változataival is kompatibilis), sőt 
az egész folyamat mindennel együtt nagyjá- 
ból félórát vett igénybe. Ha a hálózatunkban 
több WSUS-szerver is van, akkor nem árt 
viszont tudni, hogy a WSUS 2.0 képes szink- 
ronizálni az új verzióval, de a fordított eset 


nem lehetséges. 


A szerveroldali frissítés után a klienseket 
gyorsan megtalálta a WSUS 3.0, majd a fris- 
sítésük is megtörtént (a wuauclt.exe verzió- 
száma jelenleg: 7.0.5451.90). Ha már a klien- 
seknél tartunk, meg kell említenünk azt is, 
hogy az augusztus közepén kiadott Beta 2 
nem támogatta még sem a Windows Vistát, 
sem a Windows , Longhorn" Servert (akkor 
sem, ha az előző a frissítési kategóriákban 
már választható volt). 

Szeptember közepén azonban kaptunk 
hozzá pótlásképp egy frissítést, amelynek te- 
lepítése után ez a helyzet megváltozott - igaz, 
egyelőre csak a Vista RCI1 tekintetében -, de 
várhatóan a Vista-támogatás alapértelmezett 


lesz majd a jövőben. 


Kiegészítő újdonságok 

A WSUS 2.0 alapos megismerése után so- 
kunkban valószínűleg támadt némi hiány- 
érzet a kiegészítő szolgáltatások iránt. Aztán 
az interneten sorra jelentek meg azok a 
plusz szkriptek, alkalmazások (egy-kettő még 
a Microsofttól is), amelyek praktikus kiegé- 
szítőként sokat segíthettek az üzemeltetés- 
ben. Nos, a WSUS köré tartozó eszközök 
ből egy adag immár bekerült magába a ter- 
mékbe is. Ilyen újdonság a Server Cleanup 
Wizard, amellyel a lejárt frissítések, a Íris- 
sítések régebbi - már érvénytelen - verziói, 
az elutasított vagy nem használt frissítések, 
az ezekhez passzoló metaadatok és a 90 nap- 
nál régebben , látott" számítógépek is töröl 
hetők a rendszerből. A varázslás végén egy 
kategóriák szerinti összegzést is kapunk a 
,tisztogatásról" A különböző források sze- 
rint egyelőre több WSUS-szerver egy kon- 
zolon való használata esetén ezzel a kompo- 
nenssel lehetnek még problémák. 

Végül essen szó még egy új és fontos op- 
cióról, a különböző eseményekhez kapcso- 
lódó értesítési lehetőségekről, azaz például 
e-mailben kaphatunk információt a fÍrissíté- 
sek szinkronizálásáról, illetve kérhetünk na- 
pi/ heti jelentéseket, időzítve is. 

Ebben a cikkben - többek között a termék 
bétaállapota miatt - nem említhetjük meg az 
Összes apró vagy jelentősebb változást, illetve 
újdonságot, viszont a Microsoft magyar nyel 
vű lTechnetweboldalán folyamatos tájékoz- 
tatást adunk, többek között a WSUS 3.0-val 
kapcsolatban is. 

Gál Tamás 
(gtamascotiszki.hu) MCSE, MCSA, MCT, MVP 


kV 
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A PKI- 
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KIÉPÍTÉSE 


Fokozott biztonságú hitelesítő központ kialakítása elektronikus 


levélaláíráshoz, Windows PKI-infrastruktúra alapokon. 


ogyan fogjunk hozzá egy nagyléptékű Windows alapú PKlLrendszer kivitelezésének? 
Cikkünk egy közelmúltban befejezett projekt fontosabb koncepcionális követelmé- 
nyeit, a felmerült problémákat és azok kezelését, valamint a kivitelezés fázisában vá- 
lasztott megoldásokat ismerteti. Nem tekintjük ugyan feladatunknak a PKI és az intelligens 
kártyával kapcsolatos alapfogalmak tisztázását, de ha azzal kapcsolatos kérdés merülne fel az 


olvasóban, arra e-mailben szívesen válaszolunk. 


A követelmények 

Az elvárás legalább 5000 különféle, egymástól független, munkacsoportban vagy különbö- 
ző tartományi tagként üzemelő munkaállomáson digitális aláírás megvalósítása elektronikus 
levélben, több ezer felhasználó számára. A feladat magában foglalta a központi szerverinfra- 
struktúra tervezését, implementációját, valamint a kártyákkal kapcsolatos műveleteket, egé- 
szen a helyszíni telepítésig, a kártyaátadásig. 

A digitális aláíráshoz szükséges tanúsítványt és a kulcsokat is intelligens kártyán (smart 
cardon) kellett tárolnunk. Az intelligens kártyával kapcsolatos követelmények szerint a ki- 
adott tanúsítványhoz tartozó kulcsméretnek legalább 1024 bitesnek kellett lennie; a kár 
tya erőforrásait a felhasználó munkaállomásának oldaláról szabványos interfészeken (CSP, 
CAPLI/CryptoAPD) keresztül kellett elérhetővé tenni. Követelmény volt, hogy a kriptográfiai 
műveleteket szabványos APDU-üzenetekkel kell elvégezni, valamint a kártyák védelmi funk- 
ciója legalább Common Criteria szerint EAT. 3-as vagy ITISEC E2-es, illetve ezeknél maga- 
sabb garanciális szinteken legyen. 

Ezeket a követelményeket a kártyagyártók korszerű kártyái teljesítik. A mi választásunk az 
Axalto legkorszerűbb kártyájára esett. Fontos követelmény volt ezen kívül, hogy a kártyák le- 
gyenek fokozottan védettek a tanúsítvány és a titkosító kulcsok első használatáig. Ez utóbbi a 
gyakorlatban a kártyák telephelyekre történő leszállításáig és átadásáig jelent fizikai és admi- 
nisztrációs védelmet. 

Fokozott biztonságú rendszerről lévén szó nem volt szabad megfeledkezni - fizikai tárolás 
tekintetében - a PKLinfrastruktúra szervereiről sem. Ezeket olyan speciálisan elzárt helyen 
kell tárolni és üzemeltetni, amely megfelelő garanciát ad a fokozott biztonságú minősítéshez. 
Erre a leghatékonyabban a szerverszobában elhelyezett, de zárható rackszekrény kínálkozott 


megfelelő megoldásnak. A fizikai védelmet természetesen adminisztratív védelemmel kellett 
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kiegészíteni, hogy ne tudja akárki kinyitni a 
szekrényt. További biztonságfokozási célzat 
tal a CA- szerver privát kulcsát HSM modul 
lal kellett védeni. 

A szerverek rendelkezésre állásának kí 
vánt mértékét 99,5 százalékban adta meg a 
megrendelő. 

A technikai kialakítás mellett fontos sze- 
repet kapott a szabályozás. Az üzemeltetés, a 
tanúsítványkiadási, visszavonási folyamatok 
szabályozása, megoldása is a feladatunk része 
volt. Az üzemeltetést kiegészíti egy auditálási 
rend, amely biztosítja a megfeleltetést a tör- 
vényi követelményeknek. A törvényi előírá- 
sokról és egyéb rendelkezésekről részletesen 
olvashatunk például a http://www.bhsz-m. 


gov.hu/ weblapon barangolva. 


A megvalósítás 
Mint látható, a feladat egyáltalán nem volt 
egyszerű. A megrendelő kritériumrendszere 
szerint a teljes szerverrendszert 4 § 1 külön- 
álló biztonsági zónában kellett kiépíteni. A 
zónákat nemcsak fizikai szempontból, ha- 
nem adminisztratív, szabályozási oldalról is 
védetten alakítottuk ki. 

Az egyes zónák: 

1. Internetzóna - (t1) az internetes forga- 
lom, külső tűzfallal védett. 

2. DMZ webszerverzóna - két tűzfallal ha- 


tárolt, a külső tűzfalról csak a webszerverek 


Microsoft TechNet 
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érhetők el, a webszerverek viszont elérhetők 
a belső szerverzónából. 

3. Szerverzóna - a címtár és a CA-szerver 
védett zónája. 

4. Ügyfélszolgálat - az ügyfélszolgálat 
munkatársainak speciális szegmense. 

5. Az RO munkahelye - az RO számára 
(a szerepkör magyarázata később) kialakított 


speciális biztonsági zóna. 


Szerverzóna 
A szerverzóna tartalmazza a megfelelő biz- 
tonság és a választott redundáns megoldások 
szerint a szervereket. 

A tartományvezérlő szerverek a leendő fel 
használói adatbázis címtárban történő táro- 


lását, valamint a felhasználókhoz tartozó ta- 


RO munkahelye 






Szerver 
zóna 





núsítványok tárolását hivatottak megoldani. 
Mivel adatbázisról van szó, nem elég redun- 
dáns diszken tárolni az adatbázist, annak 
replikált példányát is üzemeltetni kell a meg- 
felelő rendelkezésre állás érdekében. 
CA-rszerver esetében - hasonló vizsgálatok 
eredményeképp - a diszk-ralrendszer kialakí 
tása szintén RAIDI tükrözött tömbre került. 
A CAsszerver esetében a kialakítandó infra- 
struktúra megkövetelte a V2 tanúsítványok 
használatát; ez csak és kizárólag AD integ- 
rált CA-szerveren - pontosabban Windows 
Server 2003 Enterprise Editionön - lehetsé- 
ges. A redundancia kritériumának egyedül a 
CArszerver nem tud maradéktalanul eleget 
tenni, mert a beépített HSM modul oly mér- 
tékben érzékeny a fizikai behatásokra, hogy 


VAU HELSEDNÁá E áá 


egy elhibázott mozdulatból eredő koccanás 


is tönkreteheti. 


Speciális zónák 
Tanúsítvány-adminisztrátorok esetében (ügy- 
félszolgálat és RO) - biztonsági és kompati- 
bilitási megfontolások miatt - a kialakított 
webfelületre  intelligenskártya-hitelesítéssel 
lehet csak belépni. Ez a tanúsítvány csak és 
kizárólag a hitelesítést szolgálja, a digitális 
aláírást nem. 

A CAsszerver kialakításakor kihasználtuk 
a Microsoft Windows Server 2003 Advanced 
Edition által elérhetővé tett jogok szétválasz- 
tását, amely szerint ha a CAscszerveren az 
adott jogkörhöz tartozó adminisztrációs cso- 


portba sorolt személyek más jogkörhöz tarto- 


Web 
szerverek 


internet 


zó műveletet szeretnének végezni, nem elég, 
hogy a rendszer nem engedi azt, de még a fel 


használói fiókot is zárolja. 


Belső tűzfal 

A szerverzónát védő tűzfal esetünkben ISA 
2004 lett, mivel ez volt az egyedüli olyan 
termék, amelyik képes volt a tervezés pil 
lanatában a hálózat szegmenseit egymástól 
függetlenül kezelni, valamint a szegmensek- 
hez tartozó SHIML-orgalomban tartalmi 
szűrést végezni, garantálva a szerverzóna 
sérthetetlenségét. Az ISA 2004 szerver ki- 
alakítása során figyelembe kellett vennünk 
azt a tényt, hogy a felhasználók és admin- 
munkakörök hitelesítése ezen a ponton is 


megtörténik - ráadásul intelligenskártya- 


eszközzel -, és ennek megfelelően el kell 
tudnia érni az AD címtárat. Ez csak akkor 
lehetséges, amennyiben az ISA szerver tagja 
a tartománynak, ahol a felhasználók meg- 
találhatók. A RADIUS rendszerrel kapcsolt 
(és általánosságokban is javasolt) hitelesíté- 
si módozatokat, a bonyolultabb hitelesíté- 
si eljárásokat a rendszer képtelen kezelni. 
Hosszas vizsgálódást követően arra a kö- 
vetkeztetésre jutottunk, hogy nem jelent 
többletkockázatot az ISA 2004 szerver behe- 
lyezése a belső tartományba, mivel a rend- 
szer felhasználóinak köre ismert és korlá- 
tozott. Mindezek mellett az ISA szerverben 
levő naplóállományokból egyértelműen ki 
derülhet, hogy ki, mikor és honnan próbált 
megkérdőjelezhető módszerekkel bejutni a 


rendszerbe. 


Webszerverzóna 

A CAsszervernek további funkciójaként a ki 
adandó tanúsítványok érdekében rendelkez- 
nie kell egy tanúsítványkiosztó webfelülettel. 
A megszokott felületet módosítanunk kel 
lett, ennek oka egyrészt a megrendelő által 
támasztott grafikai arculat, valamint a meg- 
változott funkcionalitás. Ennek megfelelően 
négyféle felületet valósítottunk meg. 

Végfelhasználói felület. A felhasználó a 
tanúsítvány kérését, a tanúsítvány meghosz- 
szabbítását végzi. Ennek egyszerűnek és egy- 
értelműnek kell lennie: végfelhasználói isme- 
retekkel is, magyar nyelven tudjon dolgozni 
a felhasználó. 

Ügyfélszolgálati felület. Az ügyfélszolgá- 
lati munkatárs a felhasználó kérésére felfüg- 
gesztheti a tanúsítványt, vagy felfüggesztés- 
ből képes visszaállítani az eredeti állapotra. 

Registration Authority (RA) felület. Az 
RO, az RO munkaállomáson dolgozó ad- 
minisztrátor - az ügyfélszolgálattal együtt 
működve - képes visszavonni a véglegesen 
kompromittálódott tanúsítványokat, illetve 
bizonyos speciális esetekben tanúsítványki 
adást végez. 

A tanúsítvány státuszát lekérdező felület. 
Bármely felhasználó ellenőrizni tudja, hogy 
egy rendszerben kiadott tanúsítvány az adott 
pillanatban milyen állapotban van. 

A webszerverek funkciói a CRL és Delta 
CRL publikálása, valamint a CAscszerver 
tanúsítvány közzététele. Minden PKLinfra- 
struktúra lényeges eleme, hogy mennyire 


biztos a kliensek számára oly fontos CRL és 


KK / 





— INFRASTRUKTÚRA 






Delta CRL elérhetősége. Hasonlóan az AD 
címtárakhoz, itt is törekedni kell a folyama- 
tos működést biztosító állandó elérhetőség- 
re. A lehetséges megoldásokat megvizsgálva a 
választás a Microsoft Windows Server 2003 
Web Editionre esett, amely képes NLBS szol 
gáltatáson keresztül a magas rendelkezésre 
állásra, ezen kívül a megoldásnak hatalmas 
előnye a terheléselosztás is. 

A szerverméretezések során itt is elégsé- 
gesnek bizonyult a Microsoft ajánlása, mivel 
dinamikus oldalt ez a webrendszer nem tar- 
talmaz. A CRL- és Delta CRL-állományok 
alapértelmezetten a CAscszerveren keletkez- 
nek, és ott is tárolódnak. 
Esetünkben ezeknek az ál 
lományoknak a mozgatása 
a CAcszerveren implemen- 
tált, és megfelelő jogosult 


sággal, illetve a jogszepa- 





rációt követően megfelelő 
csoporttagsággal rendelke- 
ző felhasználóhoz rendelt, 
időzítetten futó scripttel ol 
dottuk meg. A futó script 
az elkészült CRL- és Delta 
CRL-állományokat a CA- 


szerverről feltölti a webfür 
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tökre. 

A tesztek során két prob- 
lémába ütköztünk. Az el 
ső, jelentősnek nevezhető gond az volt, hogy 
a webszerver bizonyos esetekben zárolja a 
CRL- és Delta CRL-állományokat, ezáltal az 
FT P-felöltést végző script nem képes ellátni 
a feladatát. A megoldást a script időzítésé- 
nek gyakorisága jelentette, amely kompro- 
misszum ugyan, és nem teljesen up-to-date 
állapotot jelent a CA-szerver és a webfürtök 
esetében, de bőven belefért abba a 10 per 
ces tűréshatárba, amit a PKLinfrastruktúra 
ilyen esetekben képes elviselni. 

A pontos méréseink kevesebb, mint 120 
másodperces időt állapítottak meg, és ezzel 
a megoldással a megrendelő is maximálisan 
elégedett volt. A másik fő probléma bizton- 
sági kérdéseket vetett fel, ugyanis a web- 
szerverek a megrendelő többi szervere által 
is használt DMZ zónában voltak kihelyezve 
az ISA 2004 szerver egyik publikus lábára 
kötve. Az általunk alkalmazott megoldás ki- 
terjedt az FTPforgalom védelmére, ezért a 
teljes FTP-forgalmat IPSeccsatornába ágyaz- 
tuk be, preshared kulcsok használata mel 


La 


CA Cartificate (d vaarsk 
föptianai 


lett. Végezetül erre a webfürtre helyeztük ki 


az üzemeltetési szabályzatot is. 


Szerepkörök a tanúsítványkiosztóban 
Rendszergazda. Feladata a rendszer üzemel 
tetése, a rendszergazdai feladatok ellátása 
mellett a napi mentések elkészítése. 
CAscszerveradminisztrátor. Kizárólagosan 
végzi a CAscszerver tanúsítványsablonjainak 
módosítását, valamint CRL- és Delta CRL- 
állományok manuális kibocsátását. 
Biztonsági felügyelő - Security Officer 
(50). Elsősorban adminisztrációs védelem- 


mel és a fizikai hozzáférés korlátozásával védi 
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Egy tanúsítvány megújításának folyamata 


a rendszert. Esetünkben a szervereknek he- 
lyet adó rackszekrény kulcsához csak az ebbe 
a csoportba tartozó felhasználók férhetnek 
hozzá, portaszolgálaton keresztül. A másik 
alkalmazott védelem a rackszekrénybe szerelt 
KVM-kapcsolóhoz egyedi jelszóval történő 
belépés. Enélkül a rendszeradminisztrátor 
képtelen használni a szerverekhez fizikailag 
csatlakozó billentyűzetet. 

Regisztrációs felügyelő - Registration 
Officer (RO). A dedikált munkaállomásán 
tanúsítványok visszavonásával és kiadásával 
foglalkozik. A tanúsítványkiadás magában 
foglalja a rendszerüzemeltető személyzet ál 
tal használt és alkalmazott hitelesítési célt 
szolgáló tanúsítványokat is. Ez utóbbi tanú- 
sítványokat csak akkor képes kiadni az RO, 
amennyiben előtte az SO a saját kártyáján 
tárolt tanúsítvány segítségével az RO-munka- 
állomás és az ISA szerver közötti csatornát ki 
nem nyitotta. 

Ügyfélszolgálat. A helpdesk nem más, 


mint valamennyire ,butított" RO-funkció, 


CA Certificate 
Rererral 
sss Every d Years 


[tri CRL Publication 


4 months mee 


ahol az adminisztrátori személyzet csupán 
tanúsítványfelfüggesztést és felfüggesztésből 
történő helyreállítást képes kivitelezni. Ezzel 
a megoldással tehermentesítettük az RO-t, 
és még egy ellenőrzési lépcsőt iktattunk be a 

végérvényes tanúsítvány-visszavonás előtt. 
Auditor. A szerepkör elkülönül az ITüze- 
meltetéstől, és az ide sorolt munkatársak 
semmiféle kapcsolatban nem állnak a rend- 
szerüzemeltetést végző csapattal. Feladatuk 
a CAsszerveren keletkező naplóállományok 
részletes elemzése, valamint azok összevetése 
az üzemeltetési naplókkal. Napi riportokat 
készítenek a vezetés számára, amelyben jelzik 
mind a normális, mind az 


attól eltérő működést. 


Tanulságok 
Ez a cikk jól szemlélteti, 
hogy egy PKI alapú, fo- 
kozott biztonságú  rend- 
szer kialakítása egyáltalán 
Every 3 months, Nem egyszerű, és nagyon 
komoly körültekintést igé- 
nyel még úgy is (vagy pe- 
dig pont emiatt még foko- 
zottabban!), hogy az operá- 
ciós rendszerként használt 
Microsoft Windows Server 
2003 már pár kattintással 
rengeteg funkciót tesz el 
érhetővé. Az alapos tervezés és az implemen- 
táció minőségének biztosítása amiatt is elt 
engedhetetlen, hogy a kész rendszer valóban 
megfeleljen az eredeti követelményeknek, 
és adott esetben egy egyszerű szerverleállás 
vagy valamely kritikus lemez megsérülése ne 
tegye az egész informatikai rendszert teljesen 
használhatatlanná pillanatok alatt. 

A technikai megoldások mellett a projekt 
ben a fő hangsúly a folyamatok, a törvényi 
megfelelőségek biztosításán volt, ami egyre 
több cég esetében jelent egyre nagyobb kihí- 
vást. Habár a projektben csak levélaláírásra 
használtuk a tanúsítványokat, érdemes meg- 
gondolni hasonló tanúsítványkiadó kialakí- 
tását, ha a különböző tanúsítványokat köz- 
pontosítva akarjuk kezelni. 

Urbanovits György 
(Urbanovits.gyorgy(2euroone.hu), MCSE, MCT 
Kiss Mihály 

(kiss.mihaly2Deuroone.hu) MCSE 

Babócsy László 
(Babocsy.laszlo(Deuroone.hu), MCSE 
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REPORTING 
SERVICES 


Ha valaki saját alkalmazásához jelentéskészítő és megjelenítő 


eszközt szeretne illeszteni, vagy jelentésplatformot kell választania, 


akkor jól teszi, ha megismerkedik az SL Server 2005 Reporting 


Services által nyújtott alkalmazásintegrációs lehetőségekkel. 


ejlesztők, alkalmazástervezők számos alkalommal kerülnek szembe azzal a kérdéssel, 
hogy milyen eszközt, platformot használjanak saját alkalmazásaikhoz jelentéskészítésre. 
Az SOL Server Reporting Services (SSRS) megjelenéséig legtöbbször nem a Microsoft, 
hanem valamilyen más gyártó termékét kellett választaniuk, mivel a Microsoftnak egyszerűen 
nem volt jelentésplatformja. Az egyetlen valamirevaló eszköz az Access volt, ami ügyfél-kiszol 


gáló környezetben kiváló, de többrétegű vagy webalkalmazásokhoz nem való. 


Mit használjunk jelentéskészítésre? 

A Reporting Services viszont olyan jól sikerült, és olyan sokrétűen használható, illeszthető 
be a saját alkalmazásainkba, rendszereinkbe hogy ma már az esetek többségében az SSRS a 
legjobb választás. Következzen itt egy gyors - és , szubjektíven szelektív" - összefoglalás arról, 
hogy mi mindenre használható, és miért is ennyire jó az SSRS. 

Önálló jelentéskészítő, publikáló megoldásként is megáll: viszonylag egyszerű telepítés, 
konfigurálás, aztán hajrá, tolhatjuk alá a Visual Studio alapú Report Designerrel vagy a fel 
használók által egyszerűen használható Report Builderrel összerakott jelentéseket. 

A felhasználók kapnak egy portált, amelyen egyszerű eligazodni, és alig egy óra alatt meg 
lehet tanulni a használatát. A jelentéseket PDF-ben, Excelben, HTML-ben, XML-ben, CSV- 
ben, TIFEF-ben lehet nézegetni, kinyomtatni, lementeni. Meg lehet őket rendelni e-mailben, 
vagy ha úgy akarjuk, akkor minden reggel készen várhatnak minket a hálózaton lévő könyvtá- 
runkban. A rendszergazdák ugyanezt a portált használhatják publikálásra, a hozzáférés szabá- 
lyozására, paraméterek definiálására és még számos feladat megoldására. 

Többféle módon illeszthető saját alkalmazásainkhoz, portálmegoldásainkhoz. Az egyszerű 
URL-en keresztüli eléréstől egészen az általunk programozottan generált jelentések saját for- 
mátumban történő megjelenítéséig, a lehetőségek tárházát kínálja az együttműködésre. 

Tökéletesen illeszkedik a cégeknél már eddig is használt Microsofttechnológiákhoz: AD 
integrált felhasználó- és jogosultságkezeléssel rendelkezik; webszolgáltatás, . Net, WMLinter- 


fészeken keresztül programozható; szkriptelhető; skálázható; igen jól konfigurálható gyorsító- 


HAtAa 


tárral rendelkezik; webfarmot építhetünk be- 
lőle - és még sorolhatnánk. Ehelyett nézzük 
meg néhány példán keresztül, hogyan hasz- 
nálhatjuk ki legjobban a Reporting Services 
szolgáltatásait, és hogyan integrálhatjuk azt 


saját alkalmazásainkkal. 


Architektúra 
Ahhoz, hogy az SSRS által nyújtott lehetősé- 
geket lássuk, és tisztában legyünk a korlátok- 
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kal is, vessünk egy pillantást az SSRS archi- 
tektúrájára (1. ábra)! 

Az ábráról leolvasható, hogy a jelentések 
és a konfigurációs információk tárolása adat 
bázisban (SOL Server) valósul meg. A jelen- 
tések előállítása (, rendering") a felhasználói 
kérést követően a Report Serveren történik, 
nem az ügyfélalkalmazásban, és maga a je- 
lentés különböző közvetítőkön - riportpor- 
tál, e-mail, fájlszerver, programozható inter- 
fészek - keresztül jut el az ügyfélhez. 

Mivel az SSRS szervermegoldás, azaz a je- 
lentések előállítása nem az ügyfélen, hanem 
a szerveren történik, önálló, egygépes jelen- 
téskészítésre csak akkor alkalmas, ha mini 
málisan az SOL Server Express változatát és 
az Internet Information Servert is telepítjük 
az ügyfélgépre. 

(Megjegyzés: a Visual Studio 2005-ben we- 
bes és Windows-változatban is használható 
ReportViewer vezérlőelem támogatja a jelen- 
tések ügyféloldali előállítását is.) 

Az SSRS-t tehát akkor tudjuk a legjobban 
kihasználni, ha a felhasználók online elérik 
a Report Servert. A beépített (SMIP és fájl 
rendszer alapú) és bővíthető riporttovábbítá- 
si mechanizmusokkal azonban a közvetlen 
kapcsolat nélküli és kötegelt jelentéskészítést 


könnyedén meg tudjuk valósítani. 


Alkalmazásintegráció 

Alapkérdés: ha van egy webes vagy Windows- 
alkalmazásunk, hogyan használhatjuk az 
SSRS-t jelentéskészítésre, továbbá a jelenté- 
sek kezelésére? 

Természetesen többféle módon, attól füg- 
gően, hogy mit akarunk megvalósítani. Te- 
kintsük át először nagy vonalakban, aztán 
részletesebben a lehetőségeket. 

URL-elérés. Egyszerű megoldás, amelyet 
webes és Windows-alkalmazásból is használ 
hatunk. Gyorsan implementálható, viszont 
kevésbé alakítható. Lényege, hogy HTIP 
protokollon keresztül GEI/POST kéréssel 
érjük el a Report Servert, amelyen különbö- 
ző műveleteket hajthatunk végre. 

ReportViewer-vezérlőelemek. Visual Stu- 
dio 2005 webes és Windows-alkalmazások- 
ban használható vezérlőelemek. Akkor érde- 
mes használni őket, ha űrlapokon beágyaz- 
va szeretnénk jelentéseket megjeleníteni, és 
kontrollálni akarjuk a lekérdezési, megjelení- 
tési folyamatot. 


Report Server Web Service. Lehetővé 


teszi, hogy a Reporting Services minden 
szolgáltatásához hozzáférjünk az alkalmazá- 
sainkból. Mivel a jelentések megjelenítését 
általában sokkal egyszerűbben is megold- 
hatjuk, leginkább a jelentések feltöltésére, 
módosítására, törlésére, megrendelésére, jo- 
gosultságok kezelésére és tulajdonságok be- 
állítására haszhiáljuk; 

Report Definiton Language (RDL). Az 
RDL a Reporting Services jelentésdefiníciós 
nyelve. A nyelv XML alapú, nagyon jól do- 
kumentált, és kiválóan alkalmas arra, hogy 
saját alkalmazásunkból, jelentésgeneráló esz- 
közünkből Reporting Services alatt futtatha- 
tó jelentéseket gyártsunk. Egy másik fontos 
alkalmazási terület lehet a jelentések kötegelt 
módosítása, például a jelentések adatforrá- 
sául szolgáló adatbázis-struktúra megválto- 
zása miatt. 

Reporting Services Extensions. A Report 
ing Services moduláris felépítéséből adódóan 
többféleképpen bővíthető. Bizonyos esetek: 
ben a bővítés jobb megoldás 
lehet, mint a saját alkalmazá- 


( 
sunk ,reszelése", így például 





A hivatkozás az , AdventureWorks Sample 
Reports" mappa , Sales Orders Details" ri 
portját hívja meg paraméterként átadva a 
megrendelés azonosítóját. Ahogy a példa is 
mutatja, az URL-elérés nagyon egyszerűen 
használható. 

Az URL-t négy részre bonthatjuk: 

1. A Report Server elérési útvonala 

A Report Server alkalmazás URL/Jjét tar- 
talmazza, 

Példánkban https//server/reportserver 

2. A jelentés elérési útvonala 

Az URL első paramétere, egy jelentés, 
adatforrás vagy egy mappa teljes elérési útvo- 
nalát tartalmazza a szerveren belül. 

Példánkban: ?/AdventureWorks Sample 
Reports/Sales Order Detail 

3. Report Serverparancsok, -paraméterek 

A Report Servernek szóló utasítások és pa- 
raméterek, amelyek parancsokat, a jelentés 
formátumát, a bejelentkezési információt és 


egyéb feldolgozási opciókat határoznak meg. 


private void FrmMain Loadíiobject sender, Eventirgs ej 


List-ReportParameter?; reportParameters - 


new List-ReportParametec; (í]) ; 


saját adatforrásokat, jelentés- 
publikáló kiterjesztéseket és 
jelentésmegjelenítési formátu- 
mokat hozhatunk létre több- 


kevesebb programozás árán. 


this.repViewer . ProcessingMode - ProcessingMode.Remote; 
this.repViewer . ServerReport . ReportServerÜUrl1 - 

new Uri("http://server/reportserver"] ; 
this.repViewer . ServerReport . ReportPath - 

"/ adventureWorks Sample Reports/Sales Order Detail"; 


reportParameters.iddí 


new Microsoft.Reporting.WinForms.ReportParameter ( 
r"SsalesOrderNunber", "5050750")] ; 


URL-elérés 
A legegyszerűbb módja a web- 
alkalmazás-integrációnak az  ? 
URL-en keresztüli elérés. Ez 
akkor előnyös, ha a webalkalk 
mazásunkból egyszerűen aka- 
runk jelentéseket futtatni, és nem akarjuk 
különösebben felügyelni a felhasználó és a 
Report Server interakcióját. Ebben az eset 
ben az SSRS saját jelentésmegjelenítő felü- 
letén keresztül férünk hozzá a jelentések 
hez, vagy a Report Server által támogatott 
formátumok valamelyikében kérhetjük le a 
riportokat. 

Nézzünk erre egy egyszerű példát, amely 
egy webalkalmazásban http GET-et használ 


egy jelentés megjelenítésére: 


Za href — , http://server/reportserver 
"/AdventureWorks Sample Reports/Sales Order Detail 
$.rs:Command—Rendergrrs:Format—HTML4.08.rc:Link 
Target maing SalesOrderNumber— 5050/7507 — Sales 
Order 5050750 details C/a— 


this.repViewer . ServerReport . SetParameters íreportParameters] ; 


this.repViewer . RefreshReportt í] ; 


2. ábra. A példa, a Microsoft.Reporting.WinForms. ReportViewer 
vezérlőelemmel megvalósítva 


A Report Servernek szóló instrukciókat pa- 
raméterelőtagokkal látjuk el azért, hogy meg 
tudjuk őket különböztetni a jelentésparamé- 
terektől. 

Példánkban: $irs:Command-Render - 
azaz a jelentést meg akarjuk jeleníteni. 

Szrs:Format-HTML4.0 - a megjelenítési 
formátum legyen HIML 4.0. 

Szrc:!LinkTarget-main - a jelentést a 
, main" keretbe kérjük. 

4. Jelentésparaméterek 

A jelentés paraméterei, úgy, ahogy azok a 
riportdefinícióban szerepelnek, egyszerűen 
a paraméternév—érték szintaxist használhat 
juk. Ha null értéket akarunk átadni, akkor 
azt a paraméternév:isnull—true formában 


kell megadnunk. Példánkban: S.SalesOrder- 
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Number-SO50750 - a SalesOrderNumber 
paraméter értéke legyen 5050750. 

A fenti példa használható Windows-alk 
kalmazásban is: indíthatunk egy Internet 
Explorert, használhatjuk a System.Windows. 
Forms WebBrowser vezérlőelemet, ha űrlap- 
ban beágyazottan akarjuk megjeleníteni a 
jelentést, vagy nagyobb beavatkozási lehető- 
séget szeretnénk, illetve ha teljesen kézben 
akarjuk tartani a folyamatot, a System.Web. 
HttpReguest osztállyal állíthatjuk össze a ké- 
rést, míg a választ a System. Web.HttbResponse 
osztállyal dolgozhatjuk fel. 


ReportViewer-vezérlőelemek 
A Visual Studio 2005-ben webes és Win- 
dows-vezérlőelemekkel  űrlapokon mutat 
hatjuk meg a jelentéseket .Netalkalmazá- 
sainkban. Használatuk egyszerű, néhány pa- 
raméter beállításával már láthatjuk is az 
eredményt. A vezérlőelemek eseményein ke- 
resztül valamelyest ellenőrzésünk alatt tud- 
juk tartani a felhasználó-jelentés-Report 
Server interakciót, azonban magába a jelen- 
tés-előállítási folyamatba nem tudunk köz- 
vetlenül beavatkozni. A jelentés paraméte- 
reinek módosításával viszont, közvetetten, 
még ezt is meg tudjuk tenni. Természetesen 
ilyenkor a jelentést kell ennek megfelelően 
elkészítenünk. 

A Report Viewer-vezérlőelemekkel lokális 
jelentések futtatására is van lehetőségünk, 
ilyenkor a jelentés definícióját 
vagy lokális fájlban, vagy be- 


( 
ágyazott erőforrásként kezel 


zik a Reporting Services legáltalánosabban 
használható programozási interfészét. Az 
SOL Server 2005 Reporting Services két 


webszolgáltatás-belépési pontot tartalmaz. 


Report Server Web Service 
ReportService2005. Adminisztratív szolgál 
tatásokat tartalmaz, a Report 
Server beállítására, jogosult 


ságkezelésre, a jelentések fel 





ba mentjük, és egy WebBrowser vezérlőben 


jelenítjük meg. 


Reporting Services Extensions 
A Reporting Services ötféle bővítést támo- 
gat, amelyeket különböző feladatok megoldá- 


sára használhatunk. Mivel a bővítések prog- 


z?xrml version-"1.0" encoding-"utf-8" ?z 
- zReport xmlns-"http:/ /schemas.microsoft.comzsaglserver/zreporting/ 2 
xmins:rd-"http:/ /schemas.microsoft.com/SOLServer/reporting/rep 


töltésére és módosítására stb ölheszlstzésságtástaetl 
: 4 zDataSource Name-"DS4AdventureWorks"- 
A végpontot a http://server/re- c/DataSourcesz 


zBottomMargin:2.5em-c/BottomMarginz 


portserver/ReportService2005. 


asmx hivatkozáson keresztül 


érhetjük el. cBody; 


ReportExecution2005. A 


zRightMargin:2.5cem-/RightMarginz 
zPagewidth:21cmc/Pagewidthz 
zlInteractivewidth:8.Sinc/Interactivewidthza 


zColumnSpacing: 1cem-/ColumnSpacingz 
- aReportltemsz 


3 -Textbox Name- textbox1"- 


jelentések futtatására szolgáló 
webszolgáltatás-interfész.  Tá- 
mogatja jelentések tetszőleges c/Bodyz 
formátumban való lekérését, 
a paraméterek magadását, a JEE dé 
jelentéseken belüli navigációt 


3 cTable Name- table1"- 
c/Reportltemsz 
zHeight:2.00635c€m-/Heightz 


zrd: ReportID-8f5b1911-6G9ff-4237-8a55-S9f538f07f19-/rd: ReportID- 
azLeftMargin:2.5cmzejLeftMarginz 
4 -zDataSetsz 


zwWidth:12.69841cmc/WVidthz: 


alnteractiveHeightz: 11inc/InteractiveHeightz 


könyvjelzők és dokumentum- 
térképek alapján, az egyes je- 
lentéselemek láthatóságának c/Report: 
módosítását, a keresést és a 
rendezést. 

A végpontot a httb://server/reportserver/ 
ReportExecution2005.asmx hivatkozáson ke- 
resztül érhetjük el. 

A 3. ábrán látható kódrészlet az első példa 


webszolgáltatás alapú megvalósítását mutat 


private void FrmWSForm Loadiobject sender, Eventirgs ej) 


ILoca l variab led 


string reportPath - 


jük, és a jelentést lokálisan 
futtathatjuk. 

Az előzőleg említett pél 
dát a Microsoft.Reporting.Win- 


"/ adventureyWorks Sample Reports/Sales Order Detail"; 


ReportExecutionService rs 5 new ReportExecutionServiceí(]); 
rs.Credentials - System.Net.CredentialCache.DefaultCredentials; 
rs.Url : 


"hnttp:// server/reportserver/; ReportExecut ion2005 . asmx" ; 


Forms.ReportViewer vezérlő- ParameterValue[] parameters - new ParameterValue[1] ; 
FENNEN 1; parameters[0] - new ParameterValueí(); 
elemmel megvalósítva aZ áb- parameters[0] .Name - "SalesürderNunber" ; 


ra szemlélteti. Mint láthattuk 
a ReportViewer-vezérlőelemek 


egyszerűen használhatók, de 


parameters[0] . Value — "5050750"; 


Executionlnfo execIilnfo - rs.LoadReport íreportPath, historyID] ; 
rs.SetExecutionParameters (parameters, "en-usv]; 
result - rs.Renderiformat, devicelnfo, out extension, 


out encoding, out mimeType, out warnings, out streamIDs5] ; 


azért nem árt az óvatosság: ha 

a jelentés nagyon sok adatot 
jelenít meg, akkor bizony meg 
tudja terhelni a memóriát, mi- 

vel az egész jelentés letöltődik ? 
- a lapozás nem dinamikusan 
tölti a lekérdezés egyes részeit. 
Ilyen esetekben célszerű lehet saját lapozó 
mechanizmus készítése. 


A Report Serverwebszolgáltatások képe- 


NAAA 


FileStream stream - File.Createt( 

é"c:YÖrderDetail.htm", result.Lengthj) ; 
stream.Writeíresult, 0, result.Lengthj) ; 
stream. Close(]); 


this.webbrowser1.Url - new Uriifíi" ile://c:Y OrderDetail. htm") ;] 


3. ábra. Webszolgáltatás alapú megvalósítás 


ja meg: a ReportExecutionService webszolgál 
tatás-osztály Render metódusát használjuk a 


jelentés futtatására, majd a jelentést egy fájl 


zLanguagezen-US-c/Languagez 
zTopMargin:2.5Scmze/TopMarginz 
zPagekHeight:29.7em-c/PageHeightz 


4. ábra. Egy jelentés RDL-szerkezete 


ramozása nem egyszerű feladat, általában 
érdemes végiggondolni, hogy nincs-e egysze- 
rűbb út egy-egy probléma kezelésére. 

Data Processing Extension. Lehetővé 
teszi, hogy új adatforrásokkal bővítsük a 
Reporting Servicest. Írhatunk például olyan 
kiterjesztést, amelyik bináris vagy szövegfáj- 
lokból képes adatot beolvasni. Mielőtt adat 
forrás implementálásába kezdenénk, fontol 
juk meg, hogy vajon egyszerűbb-e az adatain- 
kat a Reporting Services által már kezelhető 
formába (például XML-e) konvertálni vagy 
betölteni az SOL Serverbe. 

Delivery Extension. A jelentések publi- 
kálását és megrendelését kezelhetjük vele 
tetszőleges saját megoldáson keresztül. Ké- 
szíthetünk például olyan bővítést, amelyik 
egy webszolgáltatásnak küldi el a jelentést. 
Mivel a Reporting Services beépítetten a 
fájlrendszeren keresztüli és SMTP publiká- 
lást tesz lehetővé, alternatívaként az ezeket 
használó szolgáltatások (például SOL Server 
Integration Services, Bizlalk) is alkalmasak 
az integrációra. 

Security Extension. Saját felhasználóazo- 
nosító és jogosultságkezelő rendszer imple- 


mentálását teszi lehetővé. Ez nagyon hasznos 


k 








lehet olyankor, amikor a felhasználók keze- 
lése nem AD-ben, hanem saját adatbázisban 
történik, mint például a nyilvánosan elérhe- 
tő, bejelentkezést igénylő webalkalmazások 
esetében. 

Rendering Extension. Saját megjelení- 
tési formátumok definiálását támogatja. 
Ilyen lehet például a vállalatirányítási rend- 
szer export/import formátuma, képformá- 
tumok, RSS vagy speciális szövegformátu- 
mok. Rendering Extensiont nem könnyű 
írni, akár több száz osztályt, metódust is kell 
implementálnunk, ezért célszerűbb inkább a 
beépített formátumokban készített jelentése- 
ket konvertálni. 

Report Processing Extension. A jelentés- 
feldolgozó bővítések lehetővé teszik, hogy a 
jelentésdefinícióban elhelyezett saját eleme- 
ket is feldolgozzuk, így saját jelentéseleme- 
ket definiálhatunk és jeleníthetünk meg. 
Készíthetünk például olyan bővítést, amely 
egy új grafikon típus (például tölcsérdiag- 
ram) előállítását támogatja. 

Az SOL Server 2005 Books Online min- 
den típusú bővítésre tartalmaz megfelelően 
beszédes példákat. 





A Reporting Services jelentésdefiníciós 
nyelve, az RDL egy XML alapú nyelv, amely 
igen jól dokumentált, és elég egyszerű ahhoz, 
hogy különösebb nehézség nélkül állhassunk 
neki saját jelentésgenerátorunk megírásához, 
vagy a meglévő jelentések alkalmazásból tör 
ténő módosításához. 

Egy jelentés előállításához minimálisan a 
következőket kell tennünk: 

1. Definiálnunk kell egy adatforrást a 
DataSource elem segítségével. 

2. Meg kell adnunk egy adathalmazt a 
DataSet elemmel. 

3. Létre kell hoznunk a jelentéselemeket, 
és el kell helyeznünk a jelentésen a Body/ 
RKeportltems elemben. 

A 4. ábrán látható lista egy jelentés RDL- 
szerkezetét szemlélteti, kihagyva az egyes ele- 
mek részleteit. 

Az SOL Server 2005 Books Online egy 
részletes útmutatót (ITutorial) tartalmaz, 
amely Visual Studio 2005 használatával lé- 
pésről lépésre mutatja be as RDL programo- 
zott előállítását, és körülbelül egy óra alatt 
elvégezhető. A Books Online-ban az RDL 


részletes leírását is megtaláljuk, sajnos nem 





túl sok példával, úgyhogy mielőtt nekiáll 
nánk RDL- szerkeszteni, tanulmányozzuk át 
néhány Report Designerrel készített jelentés 


forrásállományát (.rd!l fájlok). 


Összefoglalás 

A fentebb kifejtetteken kívül még számos 
egyéb eszköz áll rendelkezésünkre, hogy 
a Reporting Servicest saját környezetünk 
be illesszük. Ilyen lehetőség például a sa- 
ját assemblykben implementált függvények 
használata, az XML webszolgáltatások adat 
forrásként történő elérése, telepítő, konfigu- 
rációs szkriptek írása az rs segédprogrammal. 

Az SSRS tehát nem ,csak" egy jelentés- 
szerver és a hozzá kapcsolódó portál, hanem 
ennél sokkal több: olyan jelentésplatform, 
amelyet szinte minden alkalmazáshoz lehet 
illeszteni. 

Végezetül még egy érv az SSRS mellett: in- 
gyenes kiadásban is rendelkezésre áll, mivel 
az SOL Server Expresszel együtt letölthető - 
így az olcsóbb alkalmazásokhoz, portálmeg- 
oldásokhoz is nyugodtan használhatjuk. 

Kovács Zoltán 
(kovacsz-Oszamalk.hu) vezető oktató, Számalk 


PRODUGIS 


INFOKOMMUNIKÁCIÓS TERMÉKEK ÜZLETI DÖNTÉSHOZÓKNAK 


. informatikai döntéshozóknak és technológiai 





szakembereknek 


az elmúlt 168 óra legfontosabb hazai és külföldi, 
ICT-piaccal kapcsolatos termékbejelentések, 
hardvereszközök és termékújdonságok 


. heti ingyenes elektronikus hírlevél 


Regisztráljon! 









MM 
mp 


Microsoft TechNet 





SZOFTVERGYÁRAK 


7 . 





Mi köze van egymáshoz a kézművességnek, 


az autónak és a szoftvernek? 


szoftverek készítése ma sok esetben olyan, mint a kézművesség. A művész vázlatokat 

és tanulmányokat készít, aztán vesz egy darab friss agyagot (File - New - Project...), 

és elkezdi megtölteni tartalommal. Közben kísérletezik, visszalép, hozzátesz, elvesz, 
egyszóval teljesen egyedi műveket alkot újra és újra. Azok, akiknek rendszeresen kell éles kör 
nyezetben használt szoftvert üzleti alapon előállítaniuk (lés még nem mentek csődbe), már ki- 
dolgoztak rendszeresebb módszereket. Már van szereposztás, folyamatrendszer, és akár specia- 
lizált eszközök is rendelkezésre állnak - ez már amolyan manufaktúra. Ennél persze lehet még 
messzebb menni, vannak, akik meg is megteszik, és például fokozottabban odafigyelnek a már 
meglévő, kipróbált és bevált építőkockák újrahasznosítására is. 

A szoftvergyártás Ford I-Modellje a sablon. Egyszerű, általános céloknak megfelelő példá- 
nyokat könnyen generálhatunk, ilyenek a Visual Studio sablonjai, de még inkább az egyes 
Starter Kitek, amelyek már önmagukban is kész alkalmazások, vagy elővehetünk olyan 
kész építőkockákat, blokkokat is, mint amilyenek például a Patterns ét Practices mintái. 
Természetesen ezek vagy nagyon partikuláris igényeket elégítenek ki, és ezért ritkán igazán 
hasznosak, vagy túl általánosak, és ezért még sok munka van velük. 

Az autógyártás mai modellje a tömeges testreszabás. Kihasználják a tömeggyártás előnyeit 
- a méretgazdaságosságot, a futószalagot stb., de mégis minden megrendelőnek képesek az 
egyéni igényeihez alakítani az autóját. Előre kiválasztott kárpit, 
hangrendszer és motor kerül bele abba a karosszériába, ami csak szí- 
nében különbözik a futószalagon előtte haladótól. Ezt a működés- 
módot szeretnénk megvalósítani a szoftverek készítése során is, ez a 


szoftvergyár-koncepció. 


Mi kell egy szoftvergyárhoz? 

Ahhoz, hogy tömeges egyedi gyártást tudjunk véghez vinni, szüksé- 
günk van szerszámokra és gépekre. A szerszámokhoz és a végtermék: 
hez is szükség van tervrajzokra. A tervrajz szerepe, hogy a végső ter 
mékhez képest egyszerűsített vázzal, egy modellel tudjunk dolgozni. 

A modell pedig nem más, mint egy valódi, létező dolog egyszerűsí- 
tett leírása. Modellek segítségével könnyebben láthatunk át komplex 
rendszereket. Még ha veszítünk is az általánosítás miatt a pontosság- 
ból, ezáltal tudunk a nagy egészre koncentrálni. Ahogy egyre nő a 
szoftverek mérete és komplexitása, úgy van egyre nagyobb szükség hatékony modellezési eszkö- 
zökre, hogy a készülő rendszer biztosan helyes alapokon nyugodjon. 

Erre találták ki a modell alapú szoftverfejlesztést, amiben modelleket alkotunk, a fejleszté- 
si munkát a modell megfelelő kialakításába fektetjük, és ezután a végterméket ez alapján adja 
ki a futószalag. A végtermék azonban gyakran még mindig csak egy váz, amelyen még jelentős 
mennyiségű utómunkára van szükség, de így is hatalmas munkát spórol meg nekünk az auto- 
matizálás, hiszen kapunk egy bevált, tesztelt módszerek alapján készült, stabil alapot további 
fejlesztéseinkhez. Természetesen ez a futószalagos megoldás egyszerűen hangzik, de valakinek 


a modell modelljét és a futószalagot is ki kell fejlesztenie. 


LAT 





A szoftverfejlesztés mindeddig a lehető 
legáltalánosabb megoldásra törekedett, ilyen 
például az UML és a köré épített eszközrend- 
szerek. Maga az UML - ami egyébként kiváló 
eszköz a szoftver egyes vetületeinek modelle- 
zésére - általánossága miatt nagyon bonyo- 
lult, és nem mindig kellően , mozgékony". Az 
UML-diagramok. alapján generált vázosztá- 
lyok és kódalapok nem mindig segítenek kel 
lőképpen a tényleges fejlesztési munka során, 
emiatt még nemigen nevezhető futószalag- 
nak a szoftverfejlesztés szempontjából. 

A másik irány a RAD- (Rapid Application 
Development) eszközök esetében figyelhető 
meg; ezek a minél gyorsabb és egyszerűbb 
kódgenerálást tekintik gyakorlati célnak, és 
ehhez legtöbbször szintén modelleket hasz- 


Szoftvergyár Működése 


Projekt 


Szituáció 







Tesztelés 





A szoftvergyár belső folyamatrendszere 


nálnak. Ilyen modell például a Visual Studio 
Form Designere is, amivel Windows ablakok 
kódjának vázát készíthetjük el néhány kattin- 
tással. Ez már sokkal jobban megközelíti a 
futószalag elvét. 

A szoftvergyár-koncepció igyekszik e két 
megoldás egyensúlyát keresni, és a fejlesz- 
tő kezébe adni a választás lehetőségét, hogy 


mindenki felépíthesse magának azt a speciá- 


ir 





lis modellezési környezetet, ami a legtöbbet 
segít neki. A cél szinte mindig a meglévő és 


bevált módszer újrahasznosítása, a modell 


modell lesz például egy valódi osztályhierar- 
chia osztálydiagramja a Class Designerrel el- 


készítve vagy éppen egy ablak felülete Form 





sablonokat (text template-eket) készíthetünk, 
amelyek a modell egyes elemeit az általunk 
megkívánt végeredményre fordítják le, pél 


dául osztálydefiníciókat készítenek 




















2 Domain Properties 


1" BRM ARO O NET (H- EH GeneratedCode 


3 Decorators a- EH Resources 


a modell tulajdonságai alapján. 
Az elkészített domain-modellt 
mindjárt tesztelhetjük is, ekkor a 


Visual Studio publikálja a szüksé- 


ges elemeket, és már tervezhetjük 
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is a tényleges modellünket az ál 


talunk megadott szabályrendszer, 


vagyis a domain-modell felépítése 


I x 


szerint. (Ennél a lépésnél fontos, 


hogy a Visual Studio rendszergaz- 
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SP Name: String Hg Definition 
FP Birth : Int32 Company Name 
FR Death : Int32 ;. Name 
Name 
v :! Name of this element. 
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Egy egyszerű domain-modell a tervezőben... 


alapú, egyszerűsített és áttekinthető tervezés, 


valamint a hatékony kódgenerálás ötvözése. 


A folyamat 

De nézzük, hogyan építhetjük meg magát a 
futószalagot, vagyis a modellépítő modellt. 
Ez a domainmmodell felállításával kezdődik. 
A domainmoddell írja le, hogy szoftverünk 
modell alapú tervezésekor milyen elemek: 
ből és hogyan építhetjük fel majdani mo- 
delljeinket, és az egyes modellelemek milyen 
kódot fognak készíteni. A domain-modell 
tartalmazza az igazi know-how-t, ami idő- 
vel egyre csak gyarapodik, és akár egy gép 
vagy szerszámkészlet, önálló értéket nyer. Bár 
nem a DSL technológiát használják, de ilyen 
domain-modellnek lehet tekinteni az imént 
említett Form Designert vagy akár a Visual 
Studio 2005 UMLz:szerű Class Designerét is. 
Ezeket a domainmmodelleket az adott szoft 
verfejlesztési terület legjobb ismerői hozzák 
létre, hogy segítsék mások munkáját. 

Egy ilyen alapokon nyugvó szoftver fejlesz- 
tésekor valójában egy hatalmas, több futó- 
szalaggal rendelkező gyárnak aktiváljuk bi 
zonyos részeit. Iermészetesen a gyárból több, 
különböző típusú futószalagot is igénybe 
vehetünk egyszerre; ezek mind-mind más al 
kotóelemek elkészítéséért felelnek majd. 

Amikor a tényleges szoftvertervezésre és 
fejlesztésre kerül sor, akkor az adott domain- 
modell, vagyis futószalag kiválasztása után 
elkészíthetjük azt az egyszerűsített modellt, 


ami a létrehozandó kódot szimbolizálja. Ilyen 


Designerrel készítve. (Bár ezek nem a DSL-t 
használják, de jól szemléltetik a struktúrát. 
Aki igazi DSL-t szeretne látni működés köz- 
ben, az vessen egy pillantást a Distributed 
Systems Designerre! Ez a modell messze 
könnyebben módosítható a fejlesztés során, 
mint maga a forráskód, viszont egyetlen kat 


tintással, bármikor legenerálhatjuk belőle a 


Fabrikam 
FamilyTree 


n 


dai jogokkal fusson, mert a do- 


. 


main-modell szerelvényét a GAC- 


ba kell publikálni.) 

Konklúzió 

A szoftvergyármegközelítés és a 
DSL toolkit lehetővé teszi, hogy sokkal pro- 
fibb és hatékonyabb legyen a fejlesztési folya- 
mat. Saját magunk jelölhetjük ki a középutat 
az absztrakció és a hatékonyság között, és 
ehhez látványos eszközöket kapunk. Fontos 
még, hogy a modell megalkotásába fektetett 
energia nem hiábavaló, hiszen a következő 


iterációban a finomításnál vagy a következő 





számunkra szükséges 


r — 
4 Debu ging " Microsoft Visual Studio a 
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textto add ít to the toolbox. 


nek megfelelően. 
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a DSL Toolkit? 
A — Visual 


SDK része a Domain 


Eg Server Explorer! 34 Toolbox 


Studio ká 


Descnption 
Specific Languages 


Toolkit, ami a fenti 





folyamatot támogat — [res 
ja, illetve beilleszti .. és tesztelés közben 

a Visual Studióba. A 

DSL Designer projekt segítségével megha- 
tározhatjuk azt a domain-modellt, ami egy- 
szerre definiál egy XML alapú nyelvet és egy 
vizuális tervezőt. A modell használata során 
ezt a vizuális tervezőt tudjuk majd arra hasz- 
nálni, hogy látványosan és közérthetően ké- 
szítsünk egy modellt, az XML nyelv pedig azt 
biztosítja, hogy az emellett egzakt és szabá- 


lyos is legyen. A projekt részeként szöveges 


utána File Edit View Project Build Debug Data JIools Test Window — Community Help 
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-[ fala alta 
(EA Solution "Debugging (1 project) 
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projektben busásan megtérül az erőfeszítés. 
Akinek sikerült felkelteni az érdeklődését, 
az töltse le a SDKt, és próbálja ki a helpbben 
mellékelt oktatóanyagot, azzal sokkal kézzel 
foghatóbb lesz az egész folyamat. Aki pedig 
további cikkeket szeretne a témában olvasni, 
annak javasoljuk az MSDN oldalait. 
Nagy Levente 
(nagy.leventec Dmicrosoft.com) Microsoft Magyarország 


Microsoft TechNet 





A SHAREPOIN 
KERESŐ - 
SZOLGÁLTATÁSA 


A Sharepoint-webhelyek keresői működésének és a hibakeresés, 


tinomhangolás eszközeinek áttekintése. 


z irodai munkában manapság jellemző, hogy nagy mennyiségű, és különböző helye- 
A ken szétszórtan található információt kell folyamatosan használnia az embernek. 
Alapvetően fontos, hogy a tartalom valamilyen logikailag áttekinthető rendszerben 
legyen elrendezve. De még így is rendkívüli könnyebbséget nyújt egy olyan kereső, amelyet 
gyorsan segítségül lehet hívni, és egy-egy megfelelően kiválasztott kulcsszóval azonnal a kívánt 
tartalomra lehet lépni. A Sharepointcsaládban két kereső is van, de jó tudni a különbséget 


a Windows Sharepoint Services v2 (WSS) és a Sharepoint Portal Server 2003 (SPS) lehetősé- 


gei között. A WSS egyszerű keresőjének rövid 
tárgyalása után cikkünk az SPS jóval nagyobb 
tudású és összetettebb indexelőjének működé- 
sét vázolja fel, és igyekszik támpontokat adni 
a szolgáltatás mozzanatainak tetten éréséhez, 
ahogy arra a hibakereséshez, finomhangolás- 
hoz szükség lehet. A cikk fejtegetéseinél egy 
teljesen alapértelmezett beállításokkal telepí 
tett rendszert tekintünk hivatkozási alapnak, 
feltételezve, hogy aki valami eltérő konfigurá- 
ciót alkalmaz, az ismeri a módosításait (ame- 
lyek egyébként remélhetőleg le is vannak do- 


kumentálva). 


Windows Sharepoint Services v2 

A Sharepoint rendszer alap-iinfrastruktúrája, a 
WSS az SOL Server teljesszövegiindexeit hasz- 
nálja. Gyakorlatilag semmit nem kell és nem 
lehet rajta konfigurálni: vagy be van kapcsol 
va, vagy nincs (Központi Felügyelet - A teljes 
szövegben történő keresés beállítása). Ennek a 
keresőnek az eredményhalmaza mindig arra a 
webhelyre korlátozódik, ahol a kulcsszó beírá- 


sával elindítottuk a keresést. 


SA 


A WSS és az $PS keresőjének összehasonlítása — 1. táblázat 


Keresés célja 


Listaelemek 

Dokumentumok 

Listák 

Logikai operátorok (AND, OR, Near, NOT) 
használata 


Nem .doc, .xls, .ppt, .txt, and .htm 
típusú fájlok 


Alwebhelyek tartalma 


Nem szöveg típusú mezők 

(például pénz, szám, lookup, Igen/Nem) 
Listaelemek csatolmányai 

MS Office System 2003 dokumentumok 
tulajdonságai (Szerző, Cég) 

Felmérés típusú listák 

Rejtett listák 


Külső webhelyek, megosztott mappák, 
dokumentumok 


Keresőszóra kapott összes találat 
számának jelzése 


WSS-kereső 
Igen 
Igen 
Igen 
Nem 


Alapértelmezésben nem, de lehet 
külső iFiltereket telepíteni. 


Nem. A keresést az adott 
alwebhelyről kell indítani. 


Nem 
Nem 
Nem 


Nem 
Nem (,,by design") 


Nem 


Nem 





Ha az eredményhalmazban nem jelennek 
meg az elvárt elemek, azaz hibás működést 
sejtünk, akkor az SOL Serverbe kell elláto- 
gatni, és első lépésként a tartalom-adatbá- 
zishoz tartozó teljesszövegiindexen kell egy 
, repopulate" vagy , rebuild" műveletet végre- 


hajtani. (Amennyiben ez nem segít, érdemes 





SPS-kereső 
Igen 
Igen 
Igen 


Igen, külön programozással 
(a NOT nem támogatott). 


Igen. Bővebben az $PS2003 
, Administrators Guide"-ban. 


Igen 


Igen 
Igen 
Igen 


Igen 
Nem (,, by design") 


Igen 
Igen. Egyéni keresési lekérdezést 


kell hozzá használni. 


LA 





megnézni a 817301 és 317746 KB-cikkeket, 
illetve lehet, hogy a probléma mélyebb elem- 
zést kíván). Általában ha baj van a WSS kere- 
sőjével (azaz a tartalom-adatbázis teljesszöveg- 
indexével), akkor semmilyen eredményt nem 


kapunk. (Ilyenkor a teljesszöveg-iindexek tisz- 


tába tételével megtalálhatjuk a megoldást; 


fsz EZ 


nagy adatbázis esetén 
azonban óvatosnak 
kell lenniük: amikor 
beindul az indexelés, 
hosszabb időre is le- 
húzhatja a szerver tel 
jesítményét.) Azokon a Sharepointhelyeken, 
amelyek nem teljes SOL Serverre, hanem a 
csak a Sharepointtelepítőben található in- 
gyenes MSDE-re épülnek, a WSS-lapokon 
nem lehet bekapcsolni a keresőt, mert az 


MSDE-ben nincs teljesszöveg-iindexelés! 


Sharepoint Portal Server 2003 

A Sharepoint Portal keresője sokkal többet 
nyújt, mint a WSS (I. táblázat); persze ez- 
zel együtt a beállítás és a hibák elhárítása 
is nagyobb ráfordítást igényel. Az SPS szer- 
ves részét képező keresőmotor az egyik, ha 
nem a legfőbb szolgáltatás, ami a portálrend- 
szert a WSS-től megkülönbözteti. Ezzel az in- 
dexelővel a Sharepointlapokon kívül egyéb 
tetszőleges webes források, megosztott map- 
pák és Exchange-tárak (nyilvános mappák) 
tartalmát is bevonhatjuk a keresési ered- 
mények körébe. Szabályokkal határozhatjuk 
meg, hogy pontosan mit veszünk bele az in- 
dexelésbe, és mit zárunk ki. A Sharepoint 
tartalomban rákereshetünk konkrétan egyes 
metaadatokra (például a dokumentum szer 
zőjére, a munkatársunk tulajdonságaira stb.). 
Megadhatunk keresési tartományokat, ame- 
lyek az igényeink szerinti halmazra szűkítik a 
keresés területét, illetve némi különmunká- 
val elérhető, hogy logikai műveleteket hasz- 
nálhassunk a kulcsszavakkal (, vele VAGY 
nélküle"). 

SPS rendszereknél felmerülhet a kérdés, 
hogy ha az SPS a WSS-re épül, illetve a 
WSS-t egészíti további szolgáltatásokkal, ak- 
kor mi lesz a WSS keresőjével egy portálon. 
A válasz nem kézenfekvő: sajátos módon 
együtt él a kettő. A (gyökérszintű) portálweb- 
helyen (http:/portal/) és annak területein 
(pl. http:/portal/News) a portál keresőjét 
érhetjük el, míg az az alá rendelt WSS web- 
helyeken (például http://portal/sites/web- 


hely) a WSS keresőjét. A WSS-webhelyeket 
a portál területeitől egyrészt az URL alap- 
ján különböztethetjük meg (a WSS-lapok 
a ,.../Sites/.." virtuális könyvtár alatt talál 
hatók), másrészt a keresődoboz is másként 
néz ki. A portál keresőjénél a kulcsszavak 


bevitelére szolgáló mező mellett módunkban 





Irányított keresés 


I. ábra. Így néz ki az SPS keresője 


áll kiválasztani a keresési tartományt, illetve 
az ezektől balra lévő nagyítóikon egy link, 
amely a részletes keresés lapjára mutat. Ez 
utóbbi két funkció a WSS keresőjénél nincs 
meg (nagyítóikon van, de az nem link) (Il. és 
2. ábra). Ami mindezt igazán érdekessé teszi, 
az az, hogy a WSS-kereső továbbra is csak ar- 
ról a webhelyről ad eredményeket, ahonnan 
a keresést indítjuk, míg az SPS-kereső a tet 
szés szerint kiválasztott tartományról, azaz 
akár az egész portálról annak minden terü- 
letével és alsóbb (WSS) webhelyével együtt. 
Függetlenül tehát a WSS keresőjétől, amely 
továbbra is az SOL teljesszövegindexét hasz- 
nálja, az SPS bejárja a portált is, az alá csat 
lakozó WSS-webhelyeket, és minden egyéb 
általunk hozzáadott tartalomforrást is! Az 
SPS keresőjének mindegy, hogy épp melyik 
portálterületen állunk, amikor megadjuk a 
keresőszavakat, (ha a , Minden forrás" tar 
tományt választjuk) az összes előbb felsorolt 
helyről kaphatunk találatokat. 
Most pedig egy kicsit tekint 


sünk bele a gépezet működésébe. d. 


A Sharepoint Portal keresőmotorja 
rokona az SOL Serverének, a közös 
alapból kiindulva más-más irányba 
fejlesztették őket. Egyforma a működésük- 
ben, hogy a bejárandó tartalomból bizonyos 
szűrőkkel (iFilter) kivonják a szövegtartak 
mat. A szavaknak megkeresik a szótövét (így 
a ragozástól független keresési eredményeket 
tudnak visszaadni). Az összetett szavakat ösz- 
szetevőikre bontják, valamint figyelmen kí- 
vül hagyják az érdemi jelentés nélküli szava- 
kat (,a", ,az" stb.). 

Az SPS indexelője két folyamatban tes- 
tesül meg: az mssearch.exe-ben, amelyből 
mindig egy van, illetve az mssdmn.exe-ben, 
amelyből a tartalom bejárása alatt több is 


dolgozik egyszerre. Az mssearch.exe szolgál 





tatásként fut, és a bejárást vezényli, illetve 
a tiszta szöveg anyagból az indexeket létre- 
hozza, kezeli, majd a portálra bejövő kere- 
sési lekérdezéseket kiszolgálja. Az mssdmn. 
exe egy-egy szála az mssearch.exe-től mindig 
egy konkrét tartalomelem, dokumentum fel 
dolgozására kap megbízást, azt tiszta szöveggé 
alakítja, feldolgozza, és az eredmény vissza- 
adása után lezárul. 

A szövegtartalom alapján előállított inde- 
xeket az SPS a , cAProgram FilessSharepoint 
Portal Server DataxXkxGUID:Nsps.edb" fájl 
ban tárolja, ami nem más, mint egy JET 
adatbázis, akárcsak az Exchange-szerverek 
adattárai. A hibakeresés során ez jellemzően 
, fekete doboz", mert nem olyan , felhasználó- 
barát" a kezelése, mint egy SOL adatbázisé. 
Ezen kívül a legtöbb esetben, amikor okunk 
van feltételezni, hogy megromlott a tartalma, 
eldobhatjuk, és újragenerálhatjuk: ha az in- 
dexelőt csak a portál (esetleg néhány további, 
a vállalati hálózaton belül nagy sávszélesség- 
gel elérhető tartalomforrás) bejárására hasz- 
náljuk, akkor az indexek néhány óra vagy egy 
éjszaka alatt újragenerálhatók. 

Ebből következik, hogy nagyon mély, nagy 
ráfordítással járó hibakeresésnek ebben az 
irányban nincs is értelme. 

Természetesen vannak olyan példák 
(lés a Sharepoint portál részben pont erre 
lett kitalálva), ahol az SPS a vállalati infor- 
mációgazdálkodás csomópontja, és a sok, 


Sharepointon kívüli forrás (archivált fájlok, 


Exchange: nyilvános mappák) teljes bejárása 





2. ábra. A WSS-ben pedig ezt láthatjuk 


több napon át elnyúlik. Bár az ekkora inde- 
xek ritkák, természetesen ilyenkor óvatosab- 
ban kell őket kezelni. Néhány általános ellen- 
őrzést és javítást el lehet végezni a Sharepoint 
telepítőlemezén található eseutil.exe-vel. 
Van még egy szolgáltatás, ami az előbbiek- 
kel ellentétben a WSS és az SPS keresőjébe 
egyaránt be van építve. A keresési eredmé- 
nyek megjelenítése előtti utolsó lépés a jogo- 
sultságok ellenőrzése (, Security trimming"): 
a keresést indító felhasználó a Sharepoint 
webhelyekről kapott találatok közül csak azo- 
kat az elemeket láthatja, amelyekhez számára 


engedélyezve van a hozzáférés. Ez azt jelenti, 


Microsoft TechNet 





hogy azoknak a webhelyeknek, területeknek 
a tartalma, amelyekhez az illető a böngészés 
során nem férhet hozzá, az eredményhalmaz- 


ban sem jelenik meg. 


Ha nem jól működik 

Milyen eszközeink vannak rá, hogy belelát 
hassunk a kereső magánéletébe, ha egyálta- 
lán nem működik, lassú, vagy nem hozza a 
kívánt eredményeket? 

Mindig az eseménynaplóban kezdjük a 
kutatást; a hiba kódján és szövegén Lezek- 
re érdemes rákeresni az interneten) kívül 
az üzenetek sok esetben támpontot adnak 
teendőkkel kapcsolatban is. Az SPS képes 
részletesen naplózni működésének lépéseit a 
, cAProgram FilessSharepoint Portal Server 
Logs" könyvtárban lévő állományokba. A 
részletesség mértékét a , Központi felügyelet 
- Diagnosztikai beállítások" lapról kiindul 
va tudjuk megváltoztatni; a kereső körüli 
hibákról értékes információkhoz juthatunk, 
ha bővebbre állítjuk a , Search Service" és az 
, Administrative Service" naplózását. A hiba- 
naplókban az , exception", ,error" és , fail" 
szavak környezetében találhatunk adatokat a 


rendellenességekkel kapcsolatban. 


Content S0urce Filter Daemon 





Index Engine 


A SharePoint Portal Server keresőjének felépítése 


Amikor az indexelés nagyon lassan ha- 
lad vagy nem is fejeződik be, illetve túlzot 
tan erőforrás-igényes, arra vagyunk kíván- 
csiak, hogy milyen tartalmat dolgoz éppen 
fel, amikor így viselkedik, és hol van a rend- 
szerben a szűk keresztmetszet. Az előbbihez 
a Tartalomgyűjtő napló (Gathererlog) nyújt 
hatékony segítséget: ebben a , Webhely beál 
lításai - Keresés és indexelés konfigurálása 
- Hibák és figyelmeztetések megjelenítése: 


Portáltartalom/külső tartalom" lapon elér- 


JVEMBER 





wordbreakers 


stemmers 







Search Engine 


hető logban másodpercről másodpercre kö- 
vethetjük, hogy milyen hiba adódott a tarta- 
lom egyes elemeinek feldolgozásakor. Szoktak 
lenni olyan bejegyzések is, amelyekből nem 
olvasható ki konkrét fájlnév. Ezekből kiemel 
hetjük a ,listid" és az ,itemid" (- doclibro- 
wid) paramétereket, és az alábbi lekérdezésbe 
behelyettesítve őket, a portál tartalom-adat 
bázisából (Xportálnév: SIIE) 


juk, hogy miről van szó: 


megtudhat 


select dirname, leafname, size, metainfosize from docs 
where. listid— 31574d9b-4d11-49e2-9ea2-a125a36a- 
ba4f" and doclibrowid—186 


Amikor például külső gyártó által készí- 
tett iFiltert használunk (pdf, zip, vektorgra- 
fikus vagy egyéb fajta fájlokhoz), és az nem 
tudja megfelelően kezelni a hozzá tartozó ál 
lományokat, innen világosan kiderül a hiba. 

A Tartalomgyűjtő naplónál van mód arra 
is, hogy ne csak a hibákat jegyezze be, hanem 
a sikeresen feldolgozott vagy szándékosan 
kizárt elemek bejárását is említse (Webhely 
beállításai - Keresés és indexelés konfigurá- 
lása - Naplófájl beállításai). A hibakeresés- 


hez nagyon hasznos 


MS Search Service 


lehet ez a szolgáltatás, 
de ügyeljünk rá, hogy 
amikor már nincs rá 


akkor 
kikapcsolva, 


szükségünk, 
legyen 
Over — különben  veszélye- 
sen nagy mennyiségű 
adat halmozódhat fel 
a Cportálnév2 SERV 


adatbázisban. 





Ha elveszett erő- 
forrásaink után nyo- 
mozunk, akkor sokat 
segít a Teljesítmény- 
monitor. Érdemes 
egyrészt általános számlálók beállításával 
meggyőződni róla, hogy a gépen a procesz- 
szor, memória és merevlemez mennyire van 
igénybe véve (2. táblázat); másrészt, ha min- 
den folyamatnak figyeljük a memória- és 
processzorfogyasztását  (JoProcessor Time; 
Working set), könnyű észrevenni, hogy me- 
lyeknek vannak túlzott igényeik. Végül, de 
nem utolsósorban vegyük észre, hogy mi 
lyen sokféle számlálóval rendelkezik maga a 


Sharepointkereső. 


We ; 


Némi kísérletezéssel és intuitív használat 
tal ez utóbbiak jól kiegészítik a rálátásunkat 
a rendszerre. 

Azokban az esetekben, amikor a kere- 
ső működik, de nem adja vissza az elvárt 
eredményhalmazt, a Tartalomgyűjtő napló 
a legfontosabb forrás, illetve azt kell megfi- 
gyelni, hogy a hiányzó találatoknak milyen 
közös tulajdonságaik vannak. Egyes webla- 
pokról, tartalomforrásokból nincsenek ered- 
mények? Valamilyen dokumentumok telje- 
sen hiányoznak? 

Hiányos eredményhalmaznál az egyik leg- 
gyakoribb ok az, hogy nincs a tartalom- 
hozzáférési fióknak (Központi felügyelet - 
Kiszolgálófarm fiókbeállításainak konfigurá- 
lása) elég jogosultsága: ellenőrizni kell, hogy 
az említett fiók tagja-e az SPS-felügyeleti cso- 
portnak (Központi felügyelet - Sharepoint 
felügyeleti csoportfiók beállítása), illetve az ő 
nevében megnyitott (Futtatás mint...) böngé- 


szőből el lehete érni az adott tartalmat. 


Általános teljesítménymutatók — 


2. táblázat 





Objektum Számláló 

PTOCESSOT Percent processor time. total 

E lámEN tó bytes total per second network 
interface 

Logical disk Percent idle time 

Paging file Percent usage 

Memory Page faults per second 

System Processor gveve length 

ASP.NET applications Regvests per second total 

Web service Get regvests per second total 


Ezzel be is fejeződik a diagnosztikai kör- 
utazás, sikerült áttekinteni az eszköztárat, 
ami minden Sharepointtulajdonosnak ren- 
delkezésére áll. Talán érdemes ezek megis- 
merésére némi időt fordítani még a , boldog 
békeidőkben" is, mert általuk betekintést 
nyerhetünk a kereső működésébe, és felké- 
szültebben állhatunk neki a szerver beállí- 
tások finomhangolásának vagy az esetleges 
bajok leküzdésének. Azt pedig soha nem árt 
hangsúlyozni, hogy a szervizcsomagok (teszt 
rendszeren történő sikeres próbák utáni) te- 
lepítésével sok felesleges fejfájást takarítha- 
tunk meg. 

Pölös Máté 
(matepolkomicrosoft.com) Microsoft Magyarország 
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E KÖZÖSSÉG 





NEM SZABAD 


LEMÁARADNI 


Inkább lendületbe jövünk! 


z előző TechNet Magazin igencsak 

pozitív fogadtatása után újult erővel 

láttunk hozzá a legfrissebb szám el 
készítéséhez. Most nem egy konkrét szoftver 
re fókuszáltunk címlapsztoriként, hanem az 
informatikai infrastruktúra legáltalánosabb 
tervezési és implementációs kérdéseire kon- 
centráltunk; megnéztük, egyáltalán milyen 
állnak 


a rendelkezésünkre. 


építőelemek 


Mindezt olyan érde- 
kességek bemutatásá- 
val fűszereztük meg, 
amelyek egészen új- 
szerű, korábban igen 
nehezen megvalósít 
ható megoldásokat is 


elérhető közelségbe 


hoznak. 
Ezt követően lé- 


nyegesen mélyebbre 


MVP-k Kelet-Európából 


ásunk a mostani átte- 
kintő cikkek folytatá- 
saként. Elsőként az Exchange 2007-nek szen- 
telünk csaknem egy teljes lapszámot, majd a 
System Center termékcsaládot vesézzük ki. 
Mire pedig végzünk ezekkel, már az ajtón 
kopogtat a , Longhorn" Server is, amelyet 
szintén igyekszünk a megfelelő alapossággal 


körbejárni. 


A TechNet-modulok 


Mivel rengeteg az új, megismerésre váró tech- 
nológia, ezért a TechNet programot is átala- 
kítottuk, hogy könnyebben, kevesebb idő és 
energia ráfordításával lehessen megismerni 
a most érkező szoftvereket. A megszerezhető 


tudást igyekeztünk időben és tartalmilag is 


pj! 


rendszerezni, így születtek meg a IechNet 
modulok. 

A modulok a webcastokat (online elő- 
adásokat), szemináriumokat, és a TechNet 
Magazinokat fogják össze egy egységes in- 
formációfolyammá, így hetente pár órát kell 
csak rászánni arra, hogy mindenki maga is- 


merhesse meg a legújabb megoldásokat. 





Ebben a félévben két modult indítottunk 
útjára: az egyik a Windows Vista és a 2007-es 
Office képességeit tekinti át, a másik pedig 
az ILrendszerek infrastrukturális kérdéseivel 
foglalkozik mélyebben. 

Némi extra motivációt biztosítva -— és a ta- 
nulásra szánt időt honorálva - meglehetősen 
értékes nyereményeket sorsolunk ki azok kö- 
zött, akik a legjobb eredménnyel végeznek a 
modulokat záró, január végi IechNetkvíze- 
ken. Ezeken bárki részt vehet, és tesztelheti, 
mennyit sikerült elsajátítania az eltelt félév 
alatt a modulok tematikájából. 

Az első helyezettek egy;, illetve másfél mil 


lió forint értékben jutnak hozzá a Számalk és 


a NetAcademia által felajánlott rendszermér 
nöki képzéscsomagokhoz, de a további he- 
lyezettek is értékes könyvcsomagokat, illetve 
dobozos Windows Vista Ultimate és Office 
2007 Professional szoftvereket nyerhetnek. 

A TechNetmodulokról minden informá- 
ció közvetlenül elérhető a TechNet Portálról, 
a www.microsoft.hu/technet címen, beleért 
ve a már lezajlott valamennyi esemény és 


webcast felvételeit és prezentációit is. 


A legkiemelkedőbb szakemberek 
Szeptember végén került sor arra a találko- 
zóra, amelyik a keleteurópai MVDP-ket (Most 
Valuable Professional) hozta össze, hogy kö- 
zösen képezzék magukat tovább a Microsoft 
előadóinak segítségével, és egyúttal job- 
ban megismerjék egymást. Az MVP-k idei 
nyílt napjának Moszkva adott otthont, és 
Magyarországot is képviselte két kiváló MVP: 
Lénárd Gábor és Petrényi József. 

A nemzetközi és hazai nyílt napokon a 
Microsoft igyekszik minden segítséget meg- 
adni, hogy az MVP:k a lehető leghamarabb 
juthassanak információkhoz az újdonságok: 
kal kapcsolatban. Emellett akár közvetlenül a 
szoftvereket fejlesztő mérnökökkel is megoszt 
hatják véleményüket, illetve kikérhetik segít 
ségüket napi problémáik megoldásához. Az 
MVP-k lehetőséget kapnak arra is, hogy hoz- 
záférjenek és tanulmányozhassák a számukra 


fontos Microsoftszoftverek forráskódját. 


Nyakunkon a Vista! 

Végezetül pedig felhívjuk mindenki figyel 
mét: a legnagyobb valószínűség szerint a 
Windows Vista, az Office 2007, továbbá az 
Exchange Server 2007 végleges változata már 
október végére elkészül, és ezt erősen alá- 
támasztja, hogy már a Magazin készítésekor 
elérhető a Vista RC2-es verziója is. Lehet, 
hogy mire a lap az olvasók kezébe kerül, már 
lezárul az a hosszú és küzdelmes fejlesztési fo- 
lyamat, ami végül a Windows és az Office új 
generációját eredményezi. 

Ez lesz az a pont, amikor a legtöbb szak- 
ember elsőként próbálja majd ki ezeket az új 
szoftvereket, és elkezdenek gondolkodni az 
új képességek felhasználási lehetőségein és a 
bevezetés lépésein. Reméljük, hogy ebben a 
nem egyszerű feladatban továbbra is hasznos 
segítőtársak lehetünk a TechNettel! 

Budai Péter 
(i-pbudai(oOmicrosoft.com) Microsoft Magyarország 


Microsoft TechNet 





VEZETŐKÉPZŐ - A NETACADEMIA ÚJ TANFOLYAMSOROZATA 


VEZETC9KÉPI 





Híd az üzlet A és az informatika kö 


Ha 
0 — fontos Önnek az informatikai biztonság, 
60 nyomasztja a szabályozatlanság, 


0 meg akarja óvni a cégadatokat, 
0 — ismerős Onnek a , Kulcsember" fogalma. 


Akkor a megoldás: 
NetAcademia Vezetőképző! 


Tanfolyamsorozatunkon újfajta rálátást nyújtunk 
szakmájának legkritikusabb területeire! 


Jelentkezzen most a tanfolyamsorozatunkra! 


További információk: 
HTTPS://WWW.NETACADEMIA.NET/ 
TRAINING.ASPX?CTYPE-66 





CÍM: 1062 BUDAPEST, ANDRÁSSY ÚT 62. 


TELEFON: (06 1) 472-1214 
IRODAI MOBIL: (06 20) 369-60947 
FAX: (06 1) 472-1215 


INTERNET: WWW.NETACADEMIA.NET 
E-MAIL: INFOGCONETACADEMIA.NET 


zott 


60  elakarja kerülni az adatvesztéseket, IT katasztrófákat, 
0 tudni szeretné mi az ITIL, a BS 7799, az ISO, a COBIT, 





IDÉN FIZET, JÖVŐRE KAP! 


Vásárolja meg idei áron a jövő év szolgáltatásait! 


Ne hagyja elveszni 2006-os oktatási keretét csak azért, 
mert az év végi hajrá miatt nincs ideje a képzésekre! 


Biztosítsa be magát az , Idén fizet, jövőre kap!" akciónk 
keretében. 


A NetAcademia Oktatóközpont közel 100 tanfolyama, 
100 vizsgája és rendszerintegrátori szolgáltatása most 
még idei áron érhető el. 


Ne szalassza el a lehetőséget! 


Rendelje meg már most a képzéseket, vagy 
egyeztessen munkatársainkkal! 


További információk: 
HTTPS://WWW.NETACADEMIA.NET/ACTION.ASPX 


ACADEMIA 


A LEGJOBBAKAT TANÍTJUK. 
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Egy értéktőzsde, amely naponta 300 millió tranzakciót A NASDAG, az USA legnagyobb elektronikus 
; : értéktőzsdéje, a világ 37 országának részvényeivel 
dolgoz fel. Mégpedig Microsoft SOL Server 2005-tel. kereskedik. Létfontosságú kereskedői és üzenetközvetítő 
rendszere az SOL Server 2005-re épül, hogy képes legyen 
másodpercenként akár 64 000 tranzakció kiszolgálására is 
— mindezt 99,99996-os rendelkezésre állással." Nézze meg, 
hogyan! www.microsoft.com/bigdata 
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